All rights
reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized otherwise in any form or by any means, electronic or
mechanical, including photocopying, or posting on the internet or an intranet,
without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
This standard defines the open CityGML Conceptual Model for the storage and exchange of virtual 3D city models. The CityGML Conceptual Model is defined by a Unified Modeling Language (UML) object model. This UML model builds on the ISO Technical Committee 211 (ISO/TC211) conceptual model standards for spatial and temporal data. Building on the ISO foundation assures that the man-made features described in the city models share the same spatiotemporal universe as the surrounding countryside within which they reside.
A key goal for the development of the CityGML Conceptual Model is to provide a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields.
Introduction
An increasing number of cities and companies are building virtual 3D city models for different application areas like urban planning, mobile telecommunication, disaster management, 3D cadastre, tourism, vehicle and pedestrian navigation, facility management and environmental simulations. Furthermore, in the implementation of the European Environmental Noise Directive (END, 2002/49/EC) 3D geoinformation and 3D city models play an important role.
In recent years, most virtual 3D city models were defined as purely graphical or geometrical models, neglecting the semantic and topological aspects. Thus, these models could almost only be used for visualization purposes but not for thematic queries, analysis tasks, or spatial data mining. Since the limited reusability of models inhibits the broader use of 3D city models and may not justify the costs associated with maintaining city models, a more general modelling approach had to be taken in order to satisfy the information needs of the various application fields.
The CityGML Conceptual Model Standard defines a common semantic information model for the representation of 3D urban objects that can be shared over different applications. The latter capability is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing governments and companies to reap the benefits of their investment in 3D city models by being able to put the same models into play in different application fields. The targeted application areas explicitly include city planning, architectural design, tourist and leisure activities, environmental simulation, mobile telecommunication, disaster management, homeland security, real estate management, vehicle and pedestrian navigation, and training simulators.
The CityGML Conceptual Model defines the classes and relations for the most relevant topographic objects in cities and regional models with respect to their geometrical, topological, semantical, and appearance properties. “City” is broadly defined to comprise not just built structures, but also elevation, vegetation, water bodies, city furniture, and more. Included are generalization hierarchies between thematic classes, aggregations, relations between objects, and spatial properties. CityGML is applicable for large areas and small regions, and can represent the terrain and 3D objects in different levels of detail simultaneously. Since both simple, single scale models without topology and few semantics as well as very complex multi-scale models with full topology and fine-grained semantical differentiations can be represented, CityGML enables the consistent representation of 3D urban objects across different geographic information systems and users.
Acknowledgements
The editors wish to thank the Special Interest Group 3D (SIG 3D) of the initiative Geodata Infrastructure Germany (GDI-DE) which originally started the development of CityGML, the CityGML Standards Working Group and the 3D Information Management (3DIM) Working Group of the OGC as well as all contributors of change requests and comments.
Figure 1
This is the official CityGML logo. For current news on CityGML and information about ongoing projects and fields of research in the area of CityGML see http://www.citygml.org and http://www.citygmlwiki.org.
1 Scope
This Standard documents an OGC Conceptual Model (CM) Standard for specifying the representation of virtual 3D city and landscape models. The CityGML 3.0 Conceptual Model is a Platform Independent Model (PIM). It defines concepts in a manner which is independent of any implementing technology. As such, the CityGML CM cannot be implemented directly. Rather, it serves as the base for Platform Specific Models (PSM). A PSM adds to the PIM the technology-specific details needed to fully define the CityGML model for use with a specific technology. The PSM can then be used to generate the schema and other artifacts needed to build CityGML 3.0 implementations.
This standard does not define the PSMs nor schemas for CityGML 3.0. Future CityGML 3.0 Implementation Specifications (IS) will be developed to address this need. At a minimum, support for a Geography Markup Language (GML) Impementation Specification is expected. Additional Implementation Specifications for JSON and database schemas are also highly desirable.
The target of the conformance classes specified in this document are:
CityGML Implementation Specifications that provide encodings for the UML conceptual model specified in this document, and
Additional UML models that can be created by users to extend this conceptual model as Application Domain Extensions (ADEs).
CityGML models are comprised of georeferenced 3D vector data along with the semantics associated with the data. In contrast to other 3D vector formats, CityGML is based on a rich, general purpose information model in addition to geometry and appearance information that allows for the integration of a variety of source data to come together in a City Model. To enable the use of CityGML in specific domain areas, CityGML has historically provided an extension mechanism to enrich the data with identifiable features and properties, preserving semantic interoperability. Recognizing that an implementable expansion mechanism might have dependencies based on the encoding language, the CityGML 3.0 Conceptual Model specifies high level requirements rather than a full extension model.
Geospatial Information Model (ontology) for urban landscapes based on the ISO 19100 family.
Representation of 3D geometries, based on the ISO 19107 model, independent of data encodings, as well as of 3D point clouds.
Grouping into space hierarchies, including concepts like stories/floors within buildings.
Representation of object surface characteristics (e.g. textures, materials).
Representation of dynamic, i.e. time-dependent, properties of city models.
Taxonomies and aggregations including:
Digital Terrain Models as a combination of triangulated irregular networks (TINs), regular grids, break and skeleton lines, mass points.
Sites (currently buildings, other constructions, bridges, and tunnels).
Vegetation (areas, volumes, and solitary objects with vegetation classification).
Water bodies (volumes, surfaces).
Transportation facilities (graph structures, 3D space, and 3D surface data).
Land use (representation of areas of the earth’s surface dedicated to a specific land use).
City furniture.
Generic city objects and attributes.
User-definable (recursive) grouping.
Multiscale model with 4 well-defined consecutive Levels of Detail (LOD), applicable to both interior and exterior:
LOD0 – Highly generalized model.
LOD1 – Block model / extrusion objects.
LOD2 – Realistic, but still generalized model.
LOD3 – Highly detailed model.
Multiple representations in different LODs simultaneously and generalization relations between objects in different LODs.
Ability to combine different interior and exterior LODs, including representation of floor plans.
Optional topological connections between feature (sub)geometries.
Enables a variety of different encoding specifications, including GML and JSON.
Extension of the conceptual model through code lists, generic objects and Application Domain Extensions (ADEs).
With CityGML 3.0, ADEs become platform-independent models on a conceptual level that can be mapped to multiple and different target encodings. ADEs are implemented as UML models that extend the conceptual model in this standard. This includes a mechanism that favors the insertion of additional feature properties into any defined feature class through ‘hooks’ over subtyping of features. This means that the existing feature classes can be used and additional properties from one or more ADEs can easily be supported in different encodings.
Ability to specify an ADE that can be further extended.
2 Terms and definitions
For the purposes of this document,
the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in
standardization at the following addresses:
A set of conceptual schema for data required by one or more applications. An application schema contains selected parts of the base schemas presented in the ORM Information Viewpoint. Designers of application schemas may extend or restrict the types defined in the base schemas to define appropriate types for an application domain. Application schemas are information models for a specific information community.
quantity of information that portrays the real world
Note 1 to entry: The concept comprises data capturing rules of spatial object types, the accuracy and the types of geometries, and other aspects of a data specification. In particular, it is related to the notions of scale and resolution.
[SOURCE: ]
2.10
life-cycle information
set of properties of a spatial object that describe the temporal characteristics of a version of a spatial object or the changes between versions
[SOURCE: ]
2.11
Platform (Model Driven Architecture)
the set of resources on which a system is realized.
[SOURCE: ]
2.12
Platform Independent Model
a model that is independent of a spacific platform
[SOURCE: ]
2.13
Platform Specific Model
a model of a system that is defined in terms of a specific platform
[SOURCE: ]
3 Preface
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
4 Submitters
Table 1
Name
Affiliation
OGC member
Thomas H. Kolbe
Chair of Geoinformatics, Technical University of Munich, Germany
Yes
Tatjana Kutzner
Chair of Geoinformatics, Technical University of Munich, Germany
Yes
Carl Stephen Smyth
OpenSitePlan, USA
Yes
Claus Nagel
virtualcitySYSTEMS, Germany
Yes
Carsten Roensdorf
Ordnance Survey, Great Britain
Yes
Charles (Chuck) Heazel
HeazelTech LLC
Yes
Sylvester Hagler
U.S. National Geospatial-Intelligence Agency
Yes
In addition to the Editors of the specification the following individuals contributed to the CityGML 3.0 development:
Table 2 — Participants in Development
Name
Institution
Giorgio Agugiaro
3D Geoinformation Group, Delft University of Technology, the Netherlands
Christof Beil
Chair of Geoinformatics, Technical University of Munich, Germany
Filip Biljecki
Department of Architecture, National University of Singapore, Singapore
Kanishk Chaturvedi
Chair of Geoinformatics, Technical University of Munich, Germany
Volker Coors
Stuttgart University of Applied Sciences, Germany
Emmanuel Devys
Institut national de l’information géographique et forestière (IGN), France
Jürgen Ebbinghaus
AED-SICAD, Germany
Heinrich Geerling
Architekturbüro Geerling, Germany
Gilles Gesquière
LIRIS, University of Lyon, France
Gerhard Gröger
CPA ReDev GmbH, Germany
Karl-Heinz Häfele
Institute for Automation and Applied Informatics, Karlsruhe Institute of Technology, Germany
Nobuhiro Ishimaru
Hitachi, Ltd., Japan
Marc-Oliver Löwner
Institute for Geodesy and Photogrammetry, Technische Universität Braunschweig, Germany
Diana Moraru
Ordnance Survey, Great Britain
Friso Penninga
Geonovum, the Netherlands
Helga Tauscher
Faculty of Spatial Information, HTW Dresden — University of Applied Sciences, Germany
Linda van den Brink
Geonovum, the Netherlands
Heidi Vanparys
Danish Agency for Data Supply and Efficiency, Denmark
Sisi Zlatanova
Faculty of Built Environment, University of New South Wales, Australia
The table only lists persons that were involved in the development of CityGML 3.0. CityGML 3.0 is based on extensive previous work that was done for CityGML 2.0. For persons involved in the previous work, please refer to the CityGML 2.0 specification.
A Conceptual Model standardization target is a version of the CityGML 3.0 Conceptual Model (CM) tailored for a specific user community. This tailoring can include:
Omission of one or more of the optional UML packages
Reduction of the multiplicity for an attribute or association
Restriction on the valid values for an attribute
Additional concepts documented through ADEs.
Of these options, actions #1, #2, and #3 can be performed when creating an implementation specification. Only action #4 requires an extension of the CityGML conceptual model. These extensions are accomplished using the ADE mechanism described in Section 10 Application Domain Extensions (ADE).
Extensions of the CityGML Conceptual Model conform with the ADE Conformance Class.
5.2 Implementation Specifications
Implementation Specifications define how a Conceptual Model should be implemented using a specific technology. Conformant Implementation Specifications provide evidence that they are an accurate representation of the Conceptual Model. This evidence should include implementations of the abstract tests specified in Annex A (normative) of this document.
Since this standard is agnostic to the implementing technologies, the specific techniques to be used for conformance testing cannot be specified. Implementation Specifications need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as an annex to the Implementation Specification document.
5.3 Conformance Classes
This standard identifies seventeen (17) conformance classes. One conformance class is defined for each package in the UML model. Each conformance class is defined by one requirements class. The tests in Annex A are organized by Requirements Class. So an implementation of the Core conformance class must pass all tests specified in Annex A for the Core requirements class.
Of these seventeen conformance classes, only the Core conformance class is mandatory. All other conformance classes are optional. In the case where a conformance class has a dependency on another conformance class, that conformance class should also be implemented.
The CityGML Conceptual Model is defined by the CityGML UML model. This standard is a representation of that UML model in document form. In the case of a discrepancy between the UML model and this document, the UML model takes precedence.
6 References
[] IETF: RFC 2045 & 2046, Multipurpose Internet Mail Extensions (MIME). (November 1996),
[] INSPIRE: D2.8.III.2 Data Specification on Buildings – Technical Guidelines. European Commission Joint Research Centre.
[] ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals
[] ISO: ISO 19103:2015, Geographic Information – Conceptual Schema Language
[] ISO: ISO 19105:2000, Geographic information – Conformance and testing
[] ISO: ISO 19107:2003, Geographic Information – Spatial Schema
[] ISO: ISO 19108:2002/Cor 1:2006, Geographic information – Temporal schema — Technical Corrigendum 1
[] ISO: ISO 19109:2015, Geographic Information – Rules for Application Schemas
[] ISO: ISO 19111:2019, Geographic information – Referencing by coordinates
[] ISO: ISO 19123:2005, Geographic information — Schema for coverage geometry and functions
[] ISO: ISO 19156:2011, Geographic information – Observations and measurements
[] ISO: ISO/IEC 19505-2:2012, Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 2: Superstructure
[] ISO/IEC 19507:2012, Information technology — Object Management Group Object Constraint Language (OCL)
[] ISO: ISO/IEC 19775-1:2013 Information technology — Computer graphics, image processing and environmental data representation — Extensible 3D (X3D) — Part 1: Architecture and base components
[] Khronos Group Inc.: COLLADA – Digital Asset Schema Release 1.5.0
[] OASIS: Customer Information Quality Specifications — extensible Address Language (xAL), Version v3.0
All requirements and conformance tests that appear in this document are denoted by partial URIs relative to this base.
7.2 UML Notation
The CityGML Conceptual Model (CM) Standard is presented in this document through diagrams using the Unified Modeling Language (UML) static structure diagram (see Booch et al. 1997). The UML notations used in this standard are described in the diagram in Figure 2.
Figure 2 — UML notation (see ISO TS 19103, Geographic information — Conceptual schema language).
All associations between model elements in the CityGML Conceptual Model are uni-directional. Thus, associations in the model are navigable in only one direction. The direction of navigation is depicted by an arrowhead. In general, the context an element takes within the association is indicated by its role. The role is displayed near the target of the association. If the graphical representation is ambiguous though, the position of the role has to be drawn to the element the association points to.
The following stereotypes are used in this model:
«ApplicationSchema» denotes a conceptual schema for data required by one or more applications. In the CityGML Conceptual Model, every module is defined as a separate application schema to allow for modularization.
«FeatureType» represents features that are similar and exhibit common characteristics. Features are abstractions of real-world phenomena and have an identity.
«TopLevelFeatureType» denotes features that represent the main components of the conceptual model. Top-level features may be further semantically and spatially decomposed and substructured into parts.
«Type» denotes classes that are not directly instantiable, but are used as an abstract collection of operation, attribute and relation signatures. The stereotype is used in the CityGML Conceptual Model only for classes that are imported from the ISO standards 19107, 19109, 19111, and 19123.
«ObjectType» represents objects that have an identity, but are not features.
«DataType» defines a set of properties that lack identity. A data type is a classifier with no operations, whose primary purpose is to hold information.
«Enumeration» enumerates the valid attribute values in a fixed list of named literal values. Enumerations are specified in the CityGML Conceptual Model.
«BasicType» defines a basic data type.
«CodeList» enumerates the valid attribute values. In contrast to Enumeration, the list of values is open and, thus, not given inline in the CityGML UML Model. The allowed values can be provided within an external code list.
«Union» is a list of attributes. The semantics are that only one of the attributes can be present at any time.
«Property» denotes attributes and association roles. This stereotype does not add further semantics to the conceptual model, but is required to be able to add tagged values to the attributes and association roles that are relevant for the encoding.
«Version» denotes that the value of an association role that ends at a feature type is a specific version of the feature, not the feature in general.
In order to enhance the readability of the CityGML UML diagrams, classes are depicted in different colors. The following coloring scheme is applied:
Classes painted in yellow belong to the Requirements Class which is subject of discussion in that clause of the standard in which the UML diagram is given. For example, in the context of [rc_core_section], which introduces the CityGML Core module, the yellow color is used to denote classes that are defined in the CityGML Core Requirements Class. Likewise, the yellow classes shown in the UML diagram in [rc_building-model_section] are associated with the Building Requirements Class that is subject of discussion in that chapter.
Classes painted in blue belong to a Requirements Class different to that associated with the yellow color. In order to explicitly denote to which Requirements Class these classes belong, their class names are preceded by the UML package name of that Requirements Class. For example, in the context of the Building Requirements Class, classes from the CityGML Core and the Construction Requirements Classes are painted in blue and their class names are preceded by Core and Construction, respectively.
Classes painted in green are defined in the ISO standards 19107, 19111, or 19123. Their class names are preceded by the UML package name, in which the classes are defined.
Classes painted in grey are defined in the ISO standard 19109. In the context of this standard, this only applies to the class AnyFeature. AnyFeature is an instance of the metaclass FeatureType and acts as super class of all classes in the CityGML UML model with the stereotype «FeatureType». A metaclass is a class whose instances are classes.
The color white is used for notes and Object Constraint Language (OCL) constraints that are provided in the UML diagrams.
The example UML diagram in Figure 3 demonstrates the UML notation and coloring scheme used throughout this standard. In this example, the yellow classes are associated with the CityGML Building module, the blue classes are from the CityGML Core and Construction modules, and the green class depicts a geometry element defined by ISO 19107.
Figure 3 — Example UML diagram demonstrating the UML notation and coloring scheme used throughout the CityGML Standard.
8 Overview of CityGML
This standard defines an open CityGML Conceptual Model (CM) for the storage and exchange of virtual 3D city and landscape models. These models include the most relevant entities of the urban space like buildings, roads, railways, tunnels, bridges, city furniture, water bodies, vegetation, and the terrain. The conceptual schema specifies how and into which parts and pieces physical objects of the real world should be decomposed and classified. All objects can be represented with respect to their semantics, 3D geometry, 3D topology, appearances, and their changes over time. Different spatial representations can be provided for each object (outdoor and indoor) in four predefined Levels of Detail (LOD 0-3). The CityGML 3.0 Conceptual Model ([conceptual-model-section]) is formally specified using UML class diagrams, complemented by a data dictionary (Clause 11) providing the definitions and explanations of the object classes and attributes. This Conceptual Model is the basis for multiple encoding standards, which map the concepts (or subsets thereof) onto exchange formats or database structures for data exchange and storage.
While the CityGML Conceptual Model can be used for 3D visualization purposes, its special merits lie in applications that go beyond visualization such as decision support, urban and landscape planning, urban facility management, Smart Cities, navigation (both indoor and outdoor), Building Information Modelling (especially for as-built documentation), integration of city and BIM models, assisted and autonomous driving, and simulations in general (cf. [kolbe2009]). A comprehensive overview on the many different applications of virtual 3D city models is given in [[Biljecki2015]]. Many of the applications already use and some even require using CityGML.
In the CityGML CM, all 3D city objects can easily be enriched with thematic data. For example, street objects can be enriched with information about traffic density, speed limit, number of lanes etc., or buildings can be enriched by information on the heating and electrical energy demand, numbers of households and inhabitants, the appraised building value etc. Even building parts such as individual roof or wall surfaces can be enriched with information e.g. about solar irradiation and thermal insulation parameters. For many application domains specific extensions of the CityGML CM have already been created (cf. [biljecki2018]).
8.1 Modularization
The CityGML Conceptual Model provides models for the most important types of objects within virtual 3D city and landscape models. These feature types have been identified to be either required or important in many different application areas. However, implementations are not required to support the complete CityGML model in order to be conformant to the standard. Implementations may employ a subset of constructs according to their specific information needs. For this purpose, modularisation is applied to the CityGML CM.
Figure 4 — CityGML 3.0 module overview. The vertical boxes show the different thematic modules. Horizontal modules specify concepts that are applicable to all thematic modules.
The CityGML conceptual model is thematically decomposed into a Core module and different kinds of extension modules as shown in Figure 4. The Core module (shown in green) comprises the basic concepts and components of the CityGML CM and, thus, must be implemented by any conformant system. Each red colored module covers a specific thematic field of virtual 3D city models.
The CityGML CM introduces the following eleven thematic extension modules: Building, Bridge, Tunnel, Construction, CityFurniture, CityObjectGroup, LandUse, Relief, Transportation, Vegetation, and WaterBody. All three modules Building, Bridge, and Tunnel model civil structures and share common concepts that are grouped within the Construction module. The five blue colored extension modules add specific modelling aspects that can be used in conjunction with all thematic modules:
The Appearance module contains the concepts to represent appearances (like textures and colours) of city objects.
The PointCloud module provides concepts to represent the geometry of city objects by 3D point clouds.
The Generics module defines the concepts for generic objects, attributes, and relationships.
Versioning adds concepts for the representation of concurrent versions, real world object histories and feature histories.
The Dynamizer module contains the concepts to represent city object properties by time series data and to link them with sensors, sensor data services or external files.
Each CityGML encoding can specify support for a subset of the CityGML modules only. If a module is supported by an encoding, then all concepts should be mapped. However, the encoding specification can define so-called null mappings to restrict the use of specific elements of the conceptual model in an encoding. Null mappings can be expressed in an encoding specification for individual feature types, properties, and associations defined within a CityGML module. This means that the corresponding element will not be included in the respective encoding.
Note that also CityGML applications do not have to support all modules. Applications can also decide to only support a specific subset of CityGML modules. For example, when an application only has to work with building data, only the modules Core, Construction, and Building would have to be supported.
8.2 General Modelling Principles
8.2.1 Semantic Modelling of Real-World Objects
Real-world objects are represented by geographic features according to the definition in ISO 19109. Geographic features of the same type (e.g. buildings, roads) are modelled by corresponding feature types that are represented as classes in the Conceptual Model (CM). The objects within a 3D city model are instances of the different feature types.
In order to distinguish and reference individual objects, each object has unique identifiers. In the CityGML 3.0 CM, each geographic feature has the mandatory featureID and an optional identifier property. The featureID is used to distinguish all objects and possible multiple versions of the same real-world object. The identifier is identical for all versions of the same real-world object and can be used to reference specific objects independent from their actual object version. The featureID is unique within the same CityGML dataset, but it is generally recommended to use globally unique identifiers like UUID values or identifiers maintained by an organization such as a mapping agency. Providing globally unique and stable identifiers for the identifier attribute is recommended. This means these identifiers should remain stable over the lifetime of the real-world object.
CityGML feature types typically have a number of spatial and non-spatial properties (also called attributes) as well as relationships with other feature or object types. Note that a single CityGML object can have different spatial representations at the same time. For example, different geometry objects representing the feature’s geometry in different levels of detail or as different spatial abstractions.
Many attributes have simple, scalar values like a number or a character string. However, some attributes are complex. They do not just have a single property value. In CityGML the following types of complex attributes occur:
Qualified attribute values: For example, a measure consists of the value and a reference to the unit of measure, or e.g. for relative and absolute height levels the reference level has to also be named.
Code list values: A code list is a form of enumeration where the valid values are defined in a separate register. The code list values consist of a link or identifier for the register as well as the value from that register which is being used.
Attributes consisting of a tuple of different fields and values: For example, addresses, space occupancy, and others
Attribute value consisting of a list of numbers: For example, representing coordinate lists or matrices
In order to support feature history, CityGML 3.0 introduces bitemporal timestamps for all objects. In CityGML 2.0, the attributes creationDate and terminationDate are supported. These refer to the time period in which a specific version of an object is an integral part of the 3D city model. In 3.0, all features can now additionally have the attributes validFrom and validTo. These represent the lifespan a specific version of an object has in the real-world. Using these two time intervals a CityGML dataset could be queried both for how did the city look alike at a specific point in time as well as how did the city model look at that time.
The combination of the two types of feature identifiers and bitemporal timestamps enables encoding not only the current version of a 3D city model, but also the model’s entire history can be represented in CityGML and possibly exchanged within a single file.
8.2.2 Class Hierarchy and Inheritance of Properties and Relations
In CityGML, the specific feature types like Building, Tunnel, or WaterBody are defined as subclasses of more general higher-level classes. Hence, feature types build a hierarchy along specialization / generalization relationships where more specialized feature types inherit the properties and relationships of all their superclasses along the entire generalization path to the topmost feature type AnyFeature.
Note: A superclass is the class from which subclasses can be created.
8.2.3 Relationships between CityGML objects
In CityGML, objects can be related to each other and different types of relations are distinguished. First of all, complex objects like buildings or transportation objects typically consist of parts. These parts are individual features of their own, and can even be further decomposed. Therefore, CityGML objects can form aggregation hierarchies. Some feature types are marked in the conceptual model with the stereotype «TopLevelFeatureType». These constitute the main objects of a city model and are typically the root of an aggregation hierarchy. Only top-level features are allowed as direct members of a city model. The information about which feature types belong to the top level is required for software packages that want to filter imports, exports, and visualizations according to the general type of a city object (e.g. only show buildings, solitary vegetation objects, and roads). CityGML Application Domain Extensions should also make use of this concept, such that software tools can learn from inspecting their conceptual schema what are the main, i.e. the top-level, feature types of the extension.
Some relations in CityGML are qualified by additional parameters, typically to further specify the type of relationship. For example, a relationship can be qualified with a URI pointing to a definition of the respective relation type in an Ontology. Qualified relationships are used in CityGML, among others, for:
General relationships between features – association relatedTo between city objects,
User-defined aggregations using CityObjectGroup. This relation allows also for recursive aggregations,
External references – linking of city objects with corresponding entities from external resources like objects in a cadastre or within a BIM dataset.
The CityGML CM contains many relationships that are specifically defined between certain feature types. For example, there is the boundary relationship from 3D volumetric objects to its thematically differentiated 3D boundary surfaces. Another example is the generalizesTo relation between feature instances that represent objects on different generalisation levels.
In the CityGML 3.0 CM there are new associations to express topologic, geometric, and semantic relations between all kinds of city objects. For example, information that two rooms are adjacent or that one interior building installation (like a curtain rail) is overlapping with the spaces of two connected rooms can be expressed. The CM also enables documenting that two wall surfaces are parallel and two others are orthogonal. Also distances between objects can be represented explicitly using geometric relations. In addition to spatial relations logical relations can be expressed.
8.2.4 Definition of the Semantics for all Classes, Properties, and Relations
The meanings of all elements defined in the CityGML conceptual model are normatively specified in the data dictionary in Clause 11.
8.3 Representation of Spatial Properties
8.3.1 Geometry and Topology
Spatial properties of all CityGML feature types are represented using the geometry classes defined in ISO 19107. Spatial representations can have 0-, 1-, 2-, or 3-dimensional extents depending on the respective feature type and Levels of Detail (LOD; the LOD concept is discussed in 8.4.4 and [geometry-lod-section]). With only a few exceptions, all geometries must use 3D coordinate values. Besides primitive geometries like single points, curves, surfaces, and solids, CityGML makes use of different kinds of aggregations of geometries like spatial aggregates (MultiPoint, MultiCurve, MultiSurface, MultiSolid) and composites (CompositeCurve, CompositeSurface, CompositeSolid). Volumetric shapes are represented in ISO 19107 according to the so-called Boundary Representation (B-Rep, for explanation see [Foley2002]) only.
The CityGML Conceptual Model does not put any restriction on the usage of specific geometry types as defined in ISO 19107. For example, 3D surfaces could be represented in a dataset using 3D polygons or 3D meshes such as triangulated irregular networks (TINS) or by non-uniform rational B-spline surfaces (NURBS). However, an encoding may restrict the usage of geometry types. For example, curved lines like B-splines or clothoids, or curved surfaces like NURBS could be disallowed by explicitly defining null encodings for these concepts in the encoding specification (c.f. 8.1 above).
Note that the conceptual schema of ISO 19107 allows composite geometries to be defined by a recursive aggregation for every primitive type of the corresponding dimension. This aggregation schema allows the definition of nested aggregations (hierarchy of components). For example, a building geometry (CompositeSolid) can be composed of the house geometry (CompositeSolid) and the garage geometry (Solid), while the house’s geometry is further decomposed into the roof geometry (Solid) and the geometry of the house body (Solid). This is illustrated in Figure 5.
Figure 5 — Recursive aggregation of objects and geometries in CityGML (graphic: IGG Uni Bonn).
While the CityGML Conceptual Model does not employ the topology classes from ISO 19107, topological relations between geometries can be established by sharing geometries (typically parts of the boundary) between different geometric objects. One part of real-world space can be represented only once by a geometry object and is referenced by all features or more complex geometries which are defined or bounded by this geometry object. Thus redundancy can be avoided and explicit topological relations between parts are maintained.
Basically, there are three cases for sharing geometries:
First, two different semantic objects may be spatially represented by the same geometry object. For example, if a foot path is both a transportation feature and a vegetation feature, the surface geometry defining the path is referenced by both the transportation object and by the vegetation object.
Second, a geometry object may be shared between a feature and another geometry. For example, a geometry defining a wall of a building may be referenced twice: By the solid geometry defining the geometry of the building, and by the wall feature.
Third, two geometries may reference the same geometry, which is in the boundary of both. For example, a building and an adjacent garage may be represented by two solids. The surface describing the area where both solids touch may be represented only once and it is referenced by both solids. As it can be seen from Figure 5, this requires partitioning of the respective surfaces.
In general, B-Rep only considers visible surfaces. However, to make topological adjacency explicit and to allow the possibility of deletion of one part of a composed object without leaving holes in the remaining aggregate, touching elements are included. Whereas touching is allowed, permeation of objects is not in order to avoid the multiple representation of the same space.
Another example of sharing geometry objects that are members of the boundaries in different higher-dimensional geometry objects is the sharing of point geometries or curve geometries, which make up the outer and inner boundaries of a polygon. This means that each point is only represented once, and different polygons could reference this point geometry. The same applies to the representation of curves for transportation objects like roads, whose end points could be shared such as between different road segments to topologically connect them.
Note that the use of topology in CityGML datasets by sharing geometries is optional. Furthermore, an encoding of the CityGML conceptual model might restrict the usage of shared geometries. For example, it might only be allowed to share identical (support) points from different 3D polygons or only entire polygons can be shared between touching solids (like shown in Figure 5).
8.3.2 Prototypic Objects / Scene Graph Concepts
In CityGML, objects of equal shape like trees and other vegetation objects, traffic lights and traffic signs can be represented as prototypes which are instantiated multiple times at different locations (see Figure 6). The geometry of prototypes is defined in local coordinate systems. Every instance is represented by a reference to the prototype, a base point in the world coordinate reference system (CRS) and a transformation matrix that facilitates scaling, rotation, and translation of the prototype. The principle is adopted from the concept of scene graphs used in computer graphics standards. Since the ISO 19107 geometry model does not provide support for scene graph concepts, the CityGML class ImplicitGeometry has been introduced (for further description see [geometry-lod-section]). The prototype geometry can be represented using ISO 19107 geometry objects or by referencing an external file containing the geometry in another data format.
In addition to the spatial representations defined in the Core module, the geometry of physical spaces and of thematic surfaces can now also be provided by 3D point clouds using MultiPoint geometry. This allows, for example, spatially representing the building hull, a room within a building or a single wall surface just by a point cloud. All thematic feature types including transportation objects, vegetation, city furniture, etc. can also be spatially represented by point clouds. In this way, the ClearanceSpace of a road or railway could, for instance, be modelled directly from the result of a mobile laser scanning campaign. Point clouds can either be included in a CityGML dataset or just reference an external file of some common types such as LAS or LAZ.
8.3.4 Coordinate Reference Systems (CRS)
CityGML is about 3D city and landscape models. This means that nearly all geometries use 3D coordinates, where each single point and also the points defining the boundaries of surfaces and solids have three coordinate values (x,y,z) each. Coordinates always have to be given with respect to a coordinate reference system (CRS) that relates them unambiguously with a specific position on the Earth. In contrast to CAD or BIM, each 3D point is absolutely georeferenced, which makes CityGML especially suitable to represent geographically large extended structures like airports, railways, bridges, dams, where the Earth curvature has a significant effect on the object’s geometry (for further explanations see [Kaden2017]).
In most CRS, the (x,y) coordinates refer to the horizontal position of a point on the Earth’s surface. The z coordinate typically refers to the vertical height over (or under) the reference surface. Note that depending on the chosen CRS, x and y may be given as angular values like latitude and longitude or as distance values in meters or feet. According to ISO 19111, numerous 3D CRS can be used. This includes global as well as national reference systems using geocentric, geodetic, or projected coordinate systems.
8.4 CityGML Core Model: Space Concept, Levels of Detail, Special Spatial Types
8.4.1 Spaces and Space Boundaries
In the CityGML 3.0 Conceptual Model, a clear semantic distinction of spatial features is introduced by mapping all city objects onto the semantic concepts of spaces and space boundaries. A Space is an entity of volumetric extent in the real world. Buildings, water bodies, trees, rooms, and traffic spaces are examples for such entities with volumetric extent. A Space Boundary is an entity with areal extent in the real world. Space Boundaries delimit and connect Spaces. Examples are the wall surfaces and roof surfaces that bound a building, the water surface as boundary between the water body and air, the road surface as boundary between the ground and the traffic space, or the digital terrain model representing the space boundary between the over- and underground space.
To obtain a more precise definition of spaces, they are further subdivided into physical spaces and logical spaces. Physical spaces are spaces that are fully or partially bounded by physical objects. Buildings and rooms, for instance, are physical spaces as they are bounded by walls and slabs. Traffic spaces of roads are physical spaces as they are bounded by road surfaces against the ground. Logical spaces, in contrast, are spaces that are not necessarily bounded by physical objects, but are defined according to thematic considerations. Depending on the application, logical spaces can also be bounded by non-physical, i.e. virtual boundaries, and they can represent aggregations of physical spaces. A building unit, for instance, is a logical space as it aggregates specific rooms to flats, the rooms being the physical spaces that are bounded by wall surfaces, whereas the aggregation as a whole is being delimited by a virtual boundary. Other examples are city districts which are bounded by virtual vertically extruded administrative boundaries, public spaces vs. Security zones in airports, or city zones with specific regulations stemming from urban planning. The definition of physical and logical spaces and of corresponding physical and virtual boundaries is in line with the discussion in [[Smith2000]] on the difference between bona fide and fiat boundaries to bound objects. Bona fide boundaries are physical boundaries; they correspond to the physical boundaries of physical spaces in the CityGML 3.0 CM. In contrast, fiat boundaries are man-made boundaries. They are equivalent to the virtual boundaries of logical spaces.
Physical spaces, in turn, are further classified into occupied spaces and unoccupied spaces. Occupied spaces represent physical volumetric objects that occupy space in the urban environment. Examples for occupied spaces are buildings, bridges, trees, city furniture, and water bodies. Occupying space means that some space is blocked by these volumetric objects. For instance, the space blocked by the building in Figure 7 cannot be used any more for driving through this space or placing a tree on that space. In contrast, unoccupied spaces represent physical volumetric entities that do not occupy space in the urban environment, i.e. no space is blocked by these volumetric objects. Examples for unoccupied spaces are building rooms and traffic spaces. There is a risk of misunderstanding the term OccupiedSpace. However, we decided to use the term anyway, as it is established in the field of robotics for over three decades [[Elfes1989]]. The navigation of mobile robots makes use of a so-called occupancy map that marks areas that are occupied by matter and, thus, are not navigable for robots.
Figure 7 — Occupied and unoccupied spaces
The new space concept offers several advantages:
In the CityGML 3.0 Conceptual Model, all geometric representations are only defined in the Core module. This makes (a) models of the thematic modules simpler as they no longer need to be associated directly with the geometry classes, and (b) implementation easier as all spatial concepts have only to be implemented once in the Core module. All thematic modules like Building, Relief, WaterBody, etc. inherit their geometric representations from the Core module.
The space concept supports the expression of explicit topological, geometrical, and thematic relations between spaces and spaces, spaces and space boundaries, and space boundaries and space boundaries. Thus, implementing the checking of geometric-topological consistency will become easier. That is because most checks can be expressed and performed on the CityGML Core module and then automatically applied to all thematic modules
For the analysis of navigable spaces (e.g. to generate IndoorGML data from CityGML) algorithms can be defined on the level of the Core module. These algorithms will then work with all CityGML feature classes and also ADEs as they are derived from the Core. The same is true for other applications of 3D city models listed in [[Biljecki2015]] such as visibility analyses including shadow casting or solar irradiation analyses.
Practitioners and developers do not see much of the space concept. That is because the space and space boundary classes are just abstract classes. Only elements representing objects from concrete subclasses such as Building, BuildingRoom, or TrafficSpace will appear in CityGML data sets.
8.4.2 Modelling City Objects by the Composition of Spaces
Semantic objects in CityGML are often composed of parts, i.e. they form multi-level aggregation hierarchies. This also holds for semantic objects representing occupied and unoccupied spaces. In general, two types of compositions can be distinguished:
Spatial partitioning: Semantic objects of either the space type OccupiedSpace or UnoccupiedSpace are subdivided into different parts that are of the same space type as the parent object. Examples are Buildings that can be subdivided into BuildingParts, or Buildings that are partitioned into ConstructiveElements. Buildings as well as BuildingParts and constructiveElements represent OccupiedSpaces. Similarly, Roads can be subdivided into TrafficSpaces and AuxiliaryTrafficSpaces, all objects being UnoccupiedSpaces.
Nesting of alternating space types: Semantic objects of one space type contain objects that are of the opposite space type as the parent object. Examples are Buildings (OccupiedSpace) that contain BuildingRooms (UnoccupiedSpace), BuildingRooms (UnoccupiedSpace) that contain Furniture (OccupiedSpace), and Roads (UnoccupiedSpace) that contain CityFurniture (OccupiedSpace). The categorization of a semantic object into occupied or unoccupied takes place at the level of the object in relation to the parent object. A building is part of a city model. Thus, in the first place the building occupies urban space within a city. As long as the interior of the building is not modelled in detail, the space covered by the building needs to be considered as occupied and only viewable from the outside. To make the building accessible inside, voids need to be added to the building in the form of building rooms. The rooms add free space to the building interior. In other words, the OccupiedSpace now contains some UnoccupiedSpace. The free space inside the building can, in turn, contain objects that occupy space again, such as furniture or installations. In contrast, roads also occupy urban space in the city. However, this space is initially unoccupied as it is accessible by cars, pedestrian, or cyclists. Adding traffic signs or other city furniture objects to the free space results in specific sections of the road becoming occupied by these objects. Thus, one can also say that occupied spaces are mostly filled with matter; whereas, unoccupied spaces are mostly free of matter and, thus, realize free spaces.
8.4.3 Rules for Surface Orientations of OccupiedSpaces and UnoccupiedSpaces
The classification of feature types into OccupiedSpace and UnoccupiedSpace also defines the semantics of the geometries attached to the respective features. For OccupiedSpaces, the attached geometries describe volumes that are (mostly) physically occupied. For UnoccupiedSpaces, the attached geometries describe (or bound) volumes that are (mostly) physically unoccupied. This also has an impact on the required orientation of the surface normal (at point P this is a vector perpendicular to the tangent plane of the surface at P) for attached thematic surfaces. For OccupiedSpaces, the normal vectors of thematic surfaces must point in the same direction as the surfaces of the outer shell of the volume. For UnoccupiedSpaces, the normal vectors of thematic surfaces must point in the opposite direction as the surfaces of the outer shell of the volume. This means that from the perspective of an observer of a city scene, the surface normals must always be directed towards the observer. In the case of OccupiedSpaces (e.g. Buildings, Furniture), the observer must be located outside the OccupiedSpace for the surface normals being directed towards the observer; whereas in the case of UnoccupiedSpaces (e.g. Rooms, Roads), the observer is typically inside the UnoccupiedSpace.
8.4.4 Levels of Detail (LOD)
The CityGML Conceptual Model differentiates four consecutive Levels of Detail (LOD 0-3), where objects become more detailed with increasing LOD with respect to their geometry. CityGML datasets can — but do not have to — contain multiple geometries for each object in different LODs simultaneously. The LOD concept facilitates multi-scale modelling; i.e. having varying degrees of spatial abstractions that are appropriate for different applications or visualizations.
The classification of real-world objects into spaces and space boundaries is solely based on the semantics of these objects and not on their used geometry type, as the CityGML 3.0 CM allows various geometrical representations for objects. A building, for instance, can be spatially represented by a 3D solid (e.g. in LOD1), but at the same time, the real-world geometry can also be abstracted by a single point, footprint or roof print (LOD0), or by a 3D mesh (LOD3). The outer shell of the building may also be semantically decomposed into wall, roof, and ground surfaces. Figure 8 shows different representations of the same real-world building object in different geometric LODs (and appearances).
Figure 8 — Representation of the same real-world building in the Levels of Detail 0-3.
The biggest changes between CityGML 3.0 and earlier versions are that:
LOD4 was dropped, because now all feature types can have outdoor and indoor elements in LODs 0-3 (for those city objects where it makes sense like buildings, tunnels, or bridges). This means that the outside shell such as of a building, could be spatially represented in LOD2 and the indoor elements like rooms, doors, hallways, stairs etc. in LOD1. CityGML can now be used to represent building floor plans, which are LOD0 representations of building interiors (cf. [konde2018]). It is even possible to model the outside shell of a building in LOD1, while representing the interior structure in LOD2 or 3. Figure 9 shows different indoor/outdoor representations of a building. Details on the changes to the CityGML LOD concept are provided in [[L].
Levels of Detail are no longer associated with the degree of semantic decomposition of city objects and refer to the spatial representations only. This means that, for example, buildings can have thematic surfaces (like WallSurface, GroundSurface) also in LODs 0 and 1 and windows and doors can be represented in all LODs 0-3. In CityGML 2.0 or earlier thematic surfaces were only allowed starting from LOD2, openings like doors and windows starting from LOD3, and interior rooms and furniture only in LOD4.
In the CityGML 3.0 Conceptual Model the geometry representations were moved from the thematic modules to the Core module and are now associated with the semantic concepts of Spaces and Space Boundaries. This led to a significant simplification of the models of the thematic modules. Since all feature types in the thematic modules are defined as subclasses of the space and space boundary classes, they automatically inherit the geometry classes and, thus, no longer require direct associations with them. This also led to a harmonized LOD representation over all CityGML feature types.
If new feature types are defined in Application Domain Extensions (ADEs) based on the abstract Space and Space Boundary classes from the Core module, they automatically inherit the spatial representations and the LOD concept.
Figure 9 — Floor plan representation (LOD0) of a building (left), combined LOD2 indoor and outdoor representation (right). Image adopted from [L.
Spaces and all its subclasses like Building, Room, and TrafficSpace can now be spatially represented by single points in LOD0, multi-surfaces in LOD0/2/3, solids in LOD1/2/3, and multi-curves in LOD2/3. Space Boundaries and all its subclasses such as WallSurface, LandUse, or Relief can now be represented by multi-surfaces in LOD0/2/3 and as multi-curves in LOD2/3. See [geometry-lod-section] for further details on the different Levels of Detail.
8.4.5 Closure Surfaces
Objects, which are not spatially represented by a volumetric geometry, must be virtually closed in order to compute their volume (e.g. pedestrian underpasses or airplane hangars). They can be sealed using a specific type of space boundary called a ClosureSurface. These are virtual surfaces. They are used when a closed surface is needed to compute volumes or perform similar 3D operations. Since they do not actually exist, they are neglected when they are not needed or not appropriate. For example, ClosureSurfaces would not be used in visualizations.
The concept of ClosureSurface can also be employed to model the entrances of subsurface objects. Those objects like tunnels or pedestrian underpasses have to be modelled as closed solids in order to compute their volume. An example would be for use in flood simulations. The entrances to subsurface objects also have to be sealed to avoid holes in the digital terrain model (see Figure 10). However, in close-range visualizations the entrance should be treated as open. Thus, closure surfaces are an adequate way to model those entrances.
Figure 10 — Closure surfaces to seal open structures. Passages are subsurface objects (left). The entrance is sealed by a virtual ClosureSurface feature, which is both part of the DTM and the subsurface object (right) (graphic: IGG Uni Bonn).
8.4.6 Terrain Intersection Curves
An important issue in city modelling is the integration of 3D objects and the terrain. Problems arise if 3D objects float over or sink into the terrain. This is particularly the case when terrains and 3D objects in different LODs are combined, when the terrain and 3D models are updated independently from each other, or when they come from different data providers [[Kolbe2003]]. To overcome this problem, the TerrainIntersectionCurve (TIC) of a 3D object is introduced. These curves denote the exact position where the terrain touches the 3D object (see Figure 11). TICs can be applied to all CityGML feature types that are derived from AbstractPhysicalSpace such as buildings, bridges, tunnels, but also city furniture, vegetation, and generic city objects.
If, for example, a building has a courtyard, the TIC consists of two closed rings: One ring representing the courtyard boundary, and one which describes the building’s outer boundary. This information can be used to integrate the building and a terrain by ‘pulling up’ or ‘pulling down’ the surrounding terrain to fit the TerrainIntersectionCurve. The digital terrain model (DTM) may be locally warped to fit the TIC. By this means, the TIC also ensures the correct positioning of textures or the matching of object textures with the DTM. Since the intersection with the terrain may differ depending on the LOD, a 3D object may have different TerrainIntersectionCurves for all LODs.
Figure 11 — TerrainIntersectionCurve for a building (left, black) and a tunnel object (right, red). The tunnel’s hollow space is sealed by a triangulated ClosureSurface (graphic: IGG Uni Bonn).
8.4.7 Coherent Semantical-Geometrical Modelling
An important design principle for CityGML is the coherent modelling of semantic objects and their spatial representations. At the semantic level, real-world entities are represented by features, such as buildings, walls, windows, or rooms. The description also includes attributes, relations and aggregation hierarchies (part-whole-relations) between features. Thus the part-of-relationship between features can be derived at the semantic level only, without considering geometry. However, at the spatial level, geometry objects are assigned to features representing their spatial location, shape, and extent. So the model consists of two hierarchies: The semantic and the geometrical in which the corresponding objects are linked by relationships (cf. [stadler2007]). The advantage of this approach is that it can be navigated in both hierarchies and between both hierarchies arbitrarily, for answering thematic and/or geometrical queries or performing analyses.
If both hierarchies exist for a specific object, they must be coherent (i.e. it must be ensured that they match and fit together). For example, if a building is semantically decomposed into wall surfaces, roof surfaces and so forth, the polygons representing these thematic surfaces (in a specific LOD) must be part of the solid geometry representing the entire building (for the same LOD).
8.5 Appearances
In addition to semantics and geometry, information about the appearance of surfaces, i.e. observable properties of the surface, is considered an integral part of virtual 3D city and landscape models. Appearance relates to any surface-based theme such as infrared radiation or noise pollution, not just visual properties like RGB texture images. Consequently, data provided by appearances can be used as input for both, presentation of and analysis in virtual 3D city models.
The CityGML Conceptual Model supports feature appearances for an arbitrary number of themes per city model. Each LOD of a feature can have an individual appearance. Appearances can represent – among others – textures and georeferenced textures. CityGML’s appearance model is packaged within the Appearance module (cf. [rc_appearance_section]).
8.6 Modelling Dynamic Data
In general, city objects can have properties related to their geometry, topology, semantics, and appearance. All of these properties may change over time. For example, a construction event leads to the change in geometry of a building (i.e. addition of a new building floor or demolition of an existing door). The geometry of an object can be further classified according to its shape, location, and extent, which can also change over time. A moving car object involves changing only the location of the car object. However, a flood incident involves variations in the location and shape of water. There might be other properties, which change with respect to thematic data of city objects such as hourly variations in energy or gas consumption of a building or changing the building usage from residential to commercial. Some properties involve changes in appearances over a time period, such as building textures changing over years or traffic cameras recording videos of moving traffic over definite intervals. 3D city models also represent interrelationships between objects and relations may change over time as well. Hence, it is important to consider that the representation of time-varying data is required to be associated with these different properties. A detailed discussion on the requirements of city model applications regarding the support of dynamic data is given in [[Chaturvedi2019]].
The CityGML 3.0 Conceptual Model introduces two concepts to manage dynamic, time-dependent, properties of city models. The Versioning module manages changes that are slower in nature. Examples are (1) the history or evolution of cities such as construction or demolition of buildings, and (2) managing multiple versions of the city models.
The Dynamizer module manages higher-frequency or dynamic variations of object properties, including variations of (1) thematic attributes such as changes of physical quantities (energy demands, temperature, solar irradiation levels), (2) spatial properties such as change of a feature’s geometry, with respect to shape and location (moving objects), and (3) real-time sensor observations. The Dynamizer module allows establishing explicit links from city objects to sensors and sensor data services.
8.6.1 Versioning and Histories
As described in 8.2.1, the bitemporal timestamps of all CityGML feature types allow representing the evolution of the real city and its model over time. The new Versioning module extends this concept by the possibility of representing multiple, concurrent versions of the city model. For that purpose, the module defines two new feature types: 1) Version, which can be used to explicitly define named states of the 3D city model and denote all the specific versions of objects belonging to such states. 2) VersionTransition, which allows to explicitly link different versions of the 3D city model by describing the reason of change and the modifications applied. Details on the versioning concept are given in [[Chaturvedi2015]].
This approach not only facilitates the explicit representation of different city model versions, but also allows distinguishing and referring to different versions of city objects in an interoperable exchange format. All object versions could be stored and exchanged within a single dataset. Software systems could use such a dataset to visualize and work with the different versions simultaneously. The conceptual model also takes into account the management of multiple histories or multiple interpretations of the past of a city, which is required when looking at historical city developments and for archaeological applications. In addition, the Versioning module supports collaborative work. All functionality to represent a tree of workspaces as version control systems like git or SVN is provided. The Versioning module handles versions and version transitions as feature types, which allows the version management to be completely handled using the standard OGC Web Feature Service [[Vretanos2010]]. No extension of the OGC Web Feature Service standard is required to manage the versioning of city models.
8.6.2 Dynamizers: Using Time-Series Data for Object Attributes
The new Dynamizer module improves the usability of CityGML for different kinds of simulations as well as to facilitate the integration of devices from the Internet-of-Things (IoT) like sensors with 3D city models. Both, simulations and sensors provide dynamic variations of some measured or simulated properties such as the electricity consumption of a building or the traffic density within a road segment. The variations of the value are typically represented using time-series data. The data sources of the time-series data could be either sensor observations (e.g. from a smart meter), pre-recorded load profiles (e.g. from an energy company), or the results of some simulation run.
Figure 12 — Dynamizers link timeseries data coming from different sources to specific properties of individual city objects.
As shown in Figure 12, Dynamizers serve three main purposes:
Dynamizer is a data structure to represent dynamic values in different and generic ways. Such dynamic values may be given by (1) tabulation of time/value pairs using its AtomicTimeseries class, (2) patterns of time/value pairs based on statistical rules using its CompositeTimeseries class, and (3) retrieving observations directly from external sensor/IoT services using its SensorConnection class. The values can be obtained from sensor services such as the OGC Sensor Observation Service or OGC SensorThings API, simulation specific databases, and also external files such as CSV or Excel sheets.
Dynamizer delivers a method to enhance static city models by adding dynamic property values. A Dynamizer references a specific property (e.g. spatial, thematic or appearance properties) of a specific object within a 3D city model providing dynamic values overriding the static value of the referenced object attribute.
Dynamizer objects establish explicit links between sensor/observation data and the respective properties of city model objects that are measured by them. By making such explicit links with city object properties, the semantics of sensor data become implicitly defined by the city model.
Dynamizers are used to inject dynamic variations of city object properties into an otherwise static representation. The advantage in following such an approach is that it allows only selected properties of city models to be made dynamic. If an application does not support dynamic data, the application simply does not allow/include these special types of features.
Dynamizers have already been implemented as an Application Domain Extension (ADE) for CityGML 2.0 and were employed in the OGC Future City Pilot Phase 1. More details about Dynamizers are given in [[Chaturvedi2017]].
8.7 Extending CityGML
CityGML is designed as a universal information model that defines object types and attributes which are useful for a broad range of applications. In practical applications, the objects within specific 3D city models will most likely contain attributes which are not explicitly modelled in CityGML. Moreover, there might be 3D objects which are not covered by the CityGML CM thematic classes. The CityGML CM provides three different concepts to support the exchange of such data:
The concept of generic objects and attributes allows application-specific concepts to be represented in CityGML at runtime. This means that any city object may be augmented by additional attributes and relations, whose names, data types, and values can be provided by a running application without requiring extensions to the CityGML conceptual schema and the respective encodings. Similarly, features not represented by the predefined thematic classes of the CityGML conceptual model may be modelled and exchanged using generic objects. The generic extensions of CityGML are provided by the Generics module (cf. [rc_generics_section]).
Application Domain Extensions (ADE) specify additions to the CityGML conceptual model. Such additions comprise the introduction of new properties to existing CityGML feature types such as the energy demand of a building or the definition of additional feature types. The difference between ADEs and generic objects and attributes is, that an ADE has to be defined in an extra conceptual schema (provided in UML) with its own namespace. Encodings have to be extended accordingly. The advantage of this approach is that the extension is formally specified. Extended CityGML datasets can be validated against the CityGML CM and the respective ADE schema. ADEs can be defined (and even standardized) by information communities which are interested in specific application fields. More than one ADE can be used simultaneously in the same dataset. Examples for popular ADEs are the Utility Network ADE [[Becker2011]; [Kutzner2018]] and the Energy ADE [[Nouvel2015]; [Agugiaro2018]]. A comprehensive overview of CityGML ADEs is given in [[Biljecki2018]]. Further details on ADEs are given in Clause 12.
CityGML can also be extended with regard to the allowed values specified in code lists. Many attributes of CityGML types use a code list as a data type such as, for instance, the attributes class, usage, and function of city objects. A code list defines a value domain including a code for each permissible value. In contrast to fixed enumerations, modifications and extensions to the value domain become possible with code lists. The values for all code lists in CityGML have to be defined externally. This could, for example, be by adopting classifications from global, national, or industrial standards.
Additional information about the extension features of CityGML can be found in the CityGML 3.0 Users Guide.
AbstractConstruction is the abstract superclass for objects that are manufactured by humans from construction materials, are connected to earth, and are intended to be permanent. A connection with the ground also exists when the construction rests by its own weight on the ground or is moveable limited on stationary rails or if the construction is intended to be used mainly stationary.
AbstractConstructiveElement is the abstract superclass for the representation of volumetric elements of a construction. Examples are walls, beams, slabs.
A GroundSurface is a surface that represents the ground plate of a construction. The polygon defining the ground plate is congruent with the footprint of the construction.
An OuterCeilingSurface is a surface that belongs to the outer building shell with the orientation pointing downwards. An example is the ceiling of a loggia.
An OuterFloorSurface is a surface that belongs to the outer construction shell with the orientation pointing upwards. An example is the floor of a loggia.
AbstractAtomicTimeseries represents the attributes and relationships that are common to all kinds of atomic timeseries (GenericTimeseries, TabulatedFileTimeseries, StandardFileTimeseries). An atomic timeseries represents time-varying data of a specific data type for a single contiguous time interval.
AuthenticationTypeValue is a code list used to specify the authentication method to be used to access the referenced sensor service. Each value provides enough information such that a software application could determine the required access credentials.
A CompositeTimeseries is a (possibly recursive) aggregation of atomic and composite timeseries. The components of a composite timeseries must have non-overlapping time intervals.
A Dynamizer is an object that injects timeseries data for an individual attribute of the city object in which it is included. The timeseries data overrides the static value of the referenced city object attribute in order to represent dynamic (time-dependent) variations of its value.
A GenericTimeseries represents time-varying data in the form of embedded time-value-pairs of a specific data type for a single contiguous time interval.
SensorConnectionTypeValue is a code list used to specify the type of the referenced sensor service. Each value provides enough information such that a software application would be able to identify the API type and version.
A StandardFileTimeseries represents time-varying data for a single contiguous time interval. The data is provided in an external file referenced in the StandardFileTimeseries. The data within the external file is encoded according to a dedicated format for the representation of timeseries data such as using the OGC TimeseriesML or OGC Observations & Measurements Standard. The data type of the data has to be specified within the external file.
StandardFileTypeValue is a code list used to specify the type of the referenced external timeseries data file. Each value provides information about the standard and version.
A TabulatedFileTimeseries represents time-varying data of a specific data type for a single contiguous time interval. The data is provided in an external file referenced in the TabulatedFileTimeseries. The file contains table structured data using an appropriate file format such as comma-separated values (CSV), Microsoft Excel (XLSX) or Google Spreadsheet. The timestamps and the values are given in specific columns of the table. Each row represents a single time-value-pair. A subset of rows can be selected using the idColumn and idValue attributes.
Version represents a defined state of a city model consisting of the dedicated versions of all city object instances that belong to the respective city model version. Versions can have names, a description and can be labeled with an arbitrary number of user defined tags.
VersionTransition describes the change of the state of a city model from one version to another. Version transitions can have names, a description and can be further qualified by a type and a reason.
TransitionTypeValue enumerates the different kinds of version transitions. “planned” and “fork” should be used in cases when from one city model version multiple successor versions are being created. “realized” and “merge” should be used when different city model versions are converging into a common successor version.
A GeoreferencedTexture is a texture that uses a planimetric projection. It contains an implicit parameterization that is either stored within the image file, an accompanying world file or specified using the orientation and referencePoint elements.
A Bridge represents a structure that affords the passage of pedestrians, animals, vehicles, and service(s) above obstacles or between two points at a height above ground. [cf. ISO 6707-1]
A BridgeConstructiveElement is an element of a bridge which is essential from a structural point of view. Examples are pylons, anchorages, slabs, beams.
A BridgeInstallation is a permanent part of a Bridge (inside and/or outside) which does not have the significance of a BridgePart. In contrast to BridgeConstructiveElements, a BridgeInstallation is not essential from a structural point of view. Examples are stairs, antennas or railways.
A BridgePart is a physical or functional subdivision of a Bridge. It would be considered a Bridge, if it were not part of a collection of other BridgeParts.
A BridgeRoom is a space within a Bridge or BridgePart intended for human occupancy (e.g. a place of work or recreation) and/or containment (storage) of animals or things. A BridgeRoom is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
A Building is a free-standing, self-supporting construction that is roofed, usually walled, and can be entered by humans and is normally designed to stand permanently in one place. It is intended for human occupancy (e.g. a place of work or recreation), habitation and/or shelter of humans, animals or things.
A BuildingConstructiveElement is an element of a Building which is essential from a structural point of view. Examples are walls, slabs, staircases, beams.
A BuildingInstallation is a permanent part of a Building (inside and/or outside) which has not the significance of a BuildingPart. Examples are stairs, antennas, balconies or small roofs.
A BuildingPart is a physical or functional subdivision of a Building. It would be considered a Building, if it were not part of a collection of other BuildingParts.
A BuildingRoom is a space within a Building or BuildingPart intended for human occupancy (e.g. a place of work or recreation) and/or containment of animals or things. A BuildingRoom is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
A BuildingUnit is a logical subdivision of a Building. BuildingUnits are formed according to some homogeneous property like function, ownership, management, or accessibility. They may be separately sold, rented out, inherited, managed, etc.
A Storey is typically a horizontal section of a Building. Storeys are not always defined according to the building structure, but can also be defined according to logical considerations.
CityFurniture is an object or piece of equipment installed in the outdoor environment for various purposes. Examples include street signs, traffic signals, street lamps, benches, fountains.
A CityObjectGroup represents an application-specific aggregation of city objects according to some user-defined criteria. Examples for groups are the buildings in a specific region, the result of a query, or objects put together for visualization purposes. Each member of a group may be qualified by a role name, reflecting the role each city object plays in the context of the group.
AbstractFeatureWithLifespan is the base class for all CityGML features. This class allows the optional specification of the real-world and database times for the existence of each feature.
AbstractLogicalSpace is the abstract superclass for all types of logical spaces. Logical space refers to spaces that are not bounded by physical surfaces but are defined according to thematic considerations.
AbstractOccupiedSpace is the abstract superclass for all types of physically occupied spaces. Occupied space refers to spaces that are partially or entirely filled with matter.
AbstractPhysicalSpace is the abstract superclass for all types of physical spaces. Physical space refers to spaces that are fully or partially bounded by physical objects.
AbstractSpaceBoundary is the abstract superclass for all types of space boundaries. A space boundary is an entity with areal extent in the real world. Space boundaries are objects that bound a Space. They also realize the contact between adjacent spaces.
AbstractUnoccupiedSpace is the abstract superclass for all types of physically unoccupied spaces. Unoccupied space refers to spaces that are entirely or mostly free of matter.
DoubleBetween0and1 is a basic type for values, which are greater or equal than 0 and less or equal than 1. The type is used for color encoding, for example.
DoubleBetween0and1List is a basic type that represents a list of double values greater or equal than 0 and less or equal than 1. The type is used for color encoding, for example.
ImplicitGeometry is a geometry representation where the shape is stored only once as a prototypical geometry. Examples are a tree or other vegetation object, a traffic light or a traffic sign. This prototypic geometry object can be re-used or referenced many times, wherever the corresponding feature occurs in the 3D city model.
IntegerBetween0and3 is a basic type for integer values, which are greater or equal than 0 and less or equal than 3. The type is used for encoding the LOD number.
A LandUse object is an area of the earth’s surface dedicated to a specific land use or having a specific land cover with or without vegetation, such as sand, rock, mud flats, forest, grasslands, or wetlands.
A Hole is an opening in the surface of a Road, Track or Square such as road damages, manholes or drains. Holes can span multiple transportation objects.
An Intersection is a transportation space that is a shared segment of multiple Road, Track, Railway, or Waterway objects (e.g. a crossing of two roads or a level crossing of a road and a railway).
A Marking is a visible pattern on a transportation area relevant to the structuring or restriction of traffic. Examples are road markings and markings related to railway or waterway traffic.
A Square is a transportation space for unrestricted movement for vehicles, bicycles and/or pedestrians. This includes plazas as well as large sealed surfaces such as parking lots.
A TrafficSpace is a space in which traffic takes place. Traffic includes the movement of entities such as trains, vehicles, pedestrians, ships, or other transportation types.
A HollowSpace is a space within a Tunnel or TunnelPart intended for certain functions (e.g. transport or passage ways, service rooms, emergency shelters). A HollowSpace is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
A TunnelInstallation is a permanent part of a Tunnel (inside and/or outside) which does not have the significance of a TunnelPart. In contrast to TunnelConstructiveElement, a TunnelInstallation is not essential from a structural point of view. Examples are stairs, antennas or railings.
A TunnelPart is a physical or functional subdivision of a Tunnel. It would be considered a Tunnel, if it were not part of a collection of other TunnelParts.
A WaterSurface represents the upper exterior interface between a water body and the atmosphere.
10 CityGML Data Dictionary
10.1 Construction
10.1.1 Construction
Table 43
Description:
Parent Package:
CityGML
Stereotype:
TODO: package’ stereotype
10.1.2 Classes
Table 44
AbstractConstruction
Definition:
AbstractConstruction is the abstract superclass for objects that are manufactured by humans from construction materials, are connected to earth, and are intended to be permanent. A connection with the ground also exists when the construction rests by its own weight on the ground or is moveable limited on stationary rails or if the construction is intended to be used mainly stationary.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 52
AbstractConstructiveElement
Definition:
AbstractConstructiveElement is the abstract superclass for the representation of volumetric elements of a construction. Examples are walls, beams, slabs.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 108
GroundSurface
Definition:
A GroundSurface is a surface that represents the ground plate of a construction. The polygon defining the ground plate is congruent with the footprint of the construction.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 132
OuterCeilingSurface
Definition:
An OuterCeilingSurface is a surface that belongs to the outer building shell with the orientation pointing downwards. An example is the ceiling of a loggia.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 136
OuterFloorSurface
Definition:
An OuterFloorSurface is a surface that belongs to the outer construction shell with the orientation pointing upwards. An example is the floor of a loggia.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
10.2 Dynamizer
10.2.1 Dynamizer
Table 168
Description:
Parent Package:
CityGML
Stereotype:
TODO: package’ stereotype
10.2.2 Classes
Table 169
AbstractAtomicTimeseries
Definition:
AbstractAtomicTimeseries represents the attributes and relationships that are common to all kinds of atomic timeseries (GenericTimeseries, TabulatedFileTimeseries, StandardFileTimeseries). An atomic timeseries represents time-varying data of a specific data type for a single contiguous time interval.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 177
AuthenticationTypeValue
Definition:
AuthenticationTypeValue is a code list used to specify the authentication method to be used to access the referenced sensor service. Each value provides enough information such that a software application could determine the required access credentials.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 181
CompositeTimeseries
Definition:
A CompositeTimeseries is a (possibly recursive) aggregation of atomic and composite timeseries. The components of a composite timeseries must have non-overlapping time intervals.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 185
Dynamizer
Definition:
A Dynamizer is an object that injects timeseries data for an individual attribute of the city object in which it is included. The timeseries data overrides the static value of the referenced city object attribute in order to represent dynamic (time-dependent) variations of its value.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 189
GenericTimeseries
Definition:
A GenericTimeseries represents time-varying data in the form of embedded time-value-pairs of a specific data type for a single contiguous time interval.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 193
SensorConnectionTypeValue
Definition:
SensorConnectionTypeValue is a code list used to specify the type of the referenced sensor service. Each value provides enough information such that a software application would be able to identify the API type and version.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 197
StandardFileTimeseries
Definition:
A StandardFileTimeseries represents time-varying data for a single contiguous time interval. The data is provided in an external file referenced in the StandardFileTimeseries. The data within the external file is encoded according to a dedicated format for the representation of timeseries data such as using the OGC TimeseriesML or OGC Observations & Measurements Standard. The data type of the data has to be specified within the external file.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 201
StandardFileTypeValue
Definition:
StandardFileTypeValue is a code list used to specify the type of the referenced external timeseries data file. Each value provides information about the standard and version.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 205
TabulatedFileTimeseries
Definition:
A TabulatedFileTimeseries represents time-varying data of a specific data type for a single contiguous time interval. The data is provided in an external file referenced in the TabulatedFileTimeseries. The file contains table structured data using an appropriate file format such as comma-separated values (CSV), Microsoft Excel (XLSX) or Google Spreadsheet. The timestamps and the values are given in specific columns of the table. Each row represents a single time-value-pair. A subset of rows can be selected using the idColumn and idValue attributes.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
10.4 Versioning
10.4.1 Versioning
Table 218
Description:
Parent Package:
CityGML
Stereotype:
TODO: package’ stereotype
10.4.2 Classes
Table 219
Version
Definition:
Version represents a defined state of a city model consisting of the dedicated versions of all city object instances that belong to the respective city model version. Versions can have names, a description and can be labeled with an arbitrary number of user defined tags.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 223
VersionTransition
Definition:
VersionTransition describes the change of the state of a city model from one version to another. Version transitions can have names, a description and can be further qualified by a type and a reason.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 248
GeoreferencedTexture
Definition:
A GeoreferencedTexture is a texture that uses a planimetric projection. It contains an implicit parameterization that is either stored within the image file, an accompanying world file or specified using the orientation and referencePoint elements.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 265
Bridge
Definition:
A Bridge represents a structure that affords the passage of pedestrians, animals, vehicles, and service(s) above obstacles or between two points at a height above ground. [cf. ISO 6707-1]
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 273
BridgeConstructiveElement
Definition:
A BridgeConstructiveElement is an element of a bridge which is essential from a structural point of view. Examples are pylons, anchorages, slabs, beams.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 309
BridgeInstallation
Definition:
A BridgeInstallation is a permanent part of a Bridge (inside and/or outside) which does not have the significance of a BridgePart. In contrast to BridgeConstructiveElements, a BridgeInstallation is not essential from a structural point of view. Examples are stairs, antennas or railways.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 325
BridgePart
Definition:
A BridgePart is a physical or functional subdivision of a Bridge. It would be considered a Bridge, if it were not part of a collection of other BridgeParts.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 329
BridgeRoom
Definition:
A BridgeRoom is a space within a Bridge or BridgePart intended for human occupancy (e.g. a place of work or recreation) and/or containment (storage) of animals or things. A BridgeRoom is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 358
Building
Definition:
A Building is a free-standing, self-supporting construction that is roofed, usually walled, and can be entered by humans and is normally designed to stand permanently in one place. It is intended for human occupancy (e.g. a place of work or recreation), habitation and/or shelter of humans, animals or things.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 366
BuildingConstructiveElement
Definition:
A BuildingConstructiveElement is an element of a Building which is essential from a structural point of view. Examples are walls, slabs, staircases, beams.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 402
BuildingInstallation
Definition:
A BuildingInstallation is a permanent part of a Building (inside and/or outside) which has not the significance of a BuildingPart. Examples are stairs, antennas, balconies or small roofs.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 418
BuildingPart
Definition:
A BuildingPart is a physical or functional subdivision of a Building. It would be considered a Building, if it were not part of a collection of other BuildingParts.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 422
BuildingRoom
Definition:
A BuildingRoom is a space within a Building or BuildingPart intended for human occupancy (e.g. a place of work or recreation) and/or containment of animals or things. A BuildingRoom is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 450
BuildingUnit
Definition:
A BuildingUnit is a logical subdivision of a Building. BuildingUnits are formed according to some homogeneous property like function, ownership, management, or accessibility. They may be separately sold, rented out, inherited, managed, etc.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 466
Storey
Definition:
A Storey is typically a horizontal section of a Building. Storeys are not always defined according to the building structure, but can also be defined according to logical considerations.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
10.8 CityFurniture
10.8.1 CityFurniture
Table 470
Description:
Parent Package:
CityGML
Stereotype:
TODO: package’ stereotype
10.8.2 Classes
Table 471
CityFurniture
Definition:
CityFurniture is an object or piece of equipment installed in the outdoor environment for various purposes. Examples include street signs, traffic signals, street lamps, benches, fountains.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
10.9 CityObjectGroup
10.9.1 CityObjectGroup
Table 487
Description:
Parent Package:
CityGML
Stereotype:
TODO: package’ stereotype
10.9.2 Classes
Table 488
CityObjectGroup
Definition:
A CityObjectGroup represents an application-specific aggregation of city objects according to some user-defined criteria. Examples for groups are the buildings in a specific region, the result of a query, or objects put together for visualization purposes. Each member of a group may be qualified by a role name, reflecting the role each city object plays in the context of the group.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 521
AbstractFeatureWithLifespan
Definition:
AbstractFeatureWithLifespan is the base class for all CityGML features. This class allows the optional specification of the real-world and database times for the existence of each feature.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 525
AbstractLogicalSpace
Definition:
AbstractLogicalSpace is the abstract superclass for all types of logical spaces. Logical space refers to spaces that are not bounded by physical surfaces but are defined according to thematic considerations.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 529
AbstractOccupiedSpace
Definition:
AbstractOccupiedSpace is the abstract superclass for all types of physically occupied spaces. Occupied space refers to spaces that are partially or entirely filled with matter.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 533
AbstractPhysicalSpace
Definition:
AbstractPhysicalSpace is the abstract superclass for all types of physical spaces. Physical space refers to spaces that are fully or partially bounded by physical objects.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 545
AbstractSpaceBoundary
Definition:
AbstractSpaceBoundary is the abstract superclass for all types of space boundaries. A space boundary is an entity with areal extent in the real world. Space boundaries are objects that bound a Space. They also realize the contact between adjacent spaces.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 553
AbstractUnoccupiedSpace
Definition:
AbstractUnoccupiedSpace is the abstract superclass for all types of physically unoccupied spaces. Unoccupied space refers to spaces that are entirely or mostly free of matter.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 581
DoubleBetween0and1
Definition:
DoubleBetween0and1 is a basic type for values, which are greater or equal than 0 and less or equal than 1. The type is used for color encoding, for example.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 585
DoubleBetween0and1List
Definition:
DoubleBetween0and1List is a basic type that represents a list of double values greater or equal than 0 and less or equal than 1. The type is used for color encoding, for example.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 601
ImplicitGeometry
Definition:
ImplicitGeometry is a geometry representation where the shape is stored only once as a prototypical geometry. Examples are a tree or other vegetation object, a traffic light or a traffic sign. This prototypic geometry object can be re-used or referenced many times, wherever the corresponding feature occurs in the 3D city model.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 605
IntegerBetween0and3
Definition:
IntegerBetween0and3 is a basic type for integer values, which are greater or equal than 0 and less or equal than 3. The type is used for encoding the LOD number.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
10.12 LandUse
10.12.1 LandUse
Table 730
Description:
Parent Package:
CityGML
Stereotype:
TODO: package’ stereotype
10.12.2 Classes
Table 731
LandUse
Definition:
A LandUse object is an area of the earth’s surface dedicated to a specific land use or having a specific land cover with or without vegetation, such as sand, rock, mud flats, forest, grasslands, or wetlands.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 817
Hole
Definition:
A Hole is an opening in the surface of a Road, Track or Square such as road damages, manholes or drains. Holes can span multiple transportation objects.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 829
Intersection
Definition:
An Intersection is a transportation space that is a shared segment of multiple Road, Track, Railway, or Waterway objects (e.g. a crossing of two roads or a level crossing of a road and a railway).
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 837
Marking
Definition:
A Marking is a visible pattern on a transportation area relevant to the structuring or restriction of traffic. Examples are road markings and markings related to railway or waterway traffic.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 885
Square
Definition:
A Square is a transportation space for unrestricted movement for vehicles, bicycles and/or pedestrians. This includes plazas as well as large sealed surfaces such as parking lots.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 937
TrafficSpace
Definition:
A TrafficSpace is a space in which traffic takes place. Traffic includes the movement of entities such as trains, vehicles, pedestrians, ships, or other transportation types.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 974
HollowSpace
Definition:
A HollowSpace is a space within a Tunnel or TunnelPart intended for certain functions (e.g. transport or passage ways, service rooms, emergency shelters). A HollowSpace is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1034
TunnelInstallation
Definition:
A TunnelInstallation is a permanent part of a Tunnel (inside and/or outside) which does not have the significance of a TunnelPart. In contrast to TunnelConstructiveElement, a TunnelInstallation is not essential from a structural point of view. Examples are stairs, antennas or railings.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1050
TunnelPart
Definition:
A TunnelPart is a physical or functional subdivision of a Tunnel. It would be considered a Tunnel, if it were not part of a collection of other TunnelParts.
Specifies the 3×4 transformation matrix that defines the transformation between world coordinates and texture coordinates.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11 CityGML Data Dictionary
The CityGML UML model is the normative definition of the CityGML Conceptual Model. The Data Dictionary tables in this section were software generated from the UML model. As such, this section provides a normative representation of the CityGML Conceptual Model.
AnyFeature is an abstract class that is the generalization of all feature types. AnyFeature is an instance of the «metaclass» FeatureType [cf. ISO 19109].
A coverage that returns the same feature attribute values for every direct position within any single spatial object, temporal object or spatiotemporal object in its domain.
DirectPosition object data types (Figure 14) hold the coordinates for a position within some coordinate reference system. The coordinate reference system is described in ISO 19111. Since DirectPositions, as data types, will often be included in larger objects (such as GM_Objects) that have references to ISO19111::SC_CRS, the DirectPosition::cordinateReferenceSystem may be left NULL if this particular DirectPosition is included in a larger object with such a reference to a SC_CRS. In this case, the DirectPosition::cordinateReferenceSystem is implicitly assumed to take on the value of the containing object’s SC_CRS.
GM_Object is the root class of the geometric object taxonomy and supports interfaces common to all geographically referenced geometric objects. GM_Object instances are sets of direct positions in a particular coordinate reference system. A GM_Object can be regarded as an infinite set of points that satisfies the set operation interfaces for a set of direct positions, TransfiniteSet<DirectPosition>. Since an infinite collection class cannot be implemented directly, a Boolean test for inclusion shall be provided by the GM_Object interface. This international standard concentrates on vector geometry classes, but future work may use GM_Object as a root class without modification.
NOTE As a type, GM_Object does not have a well-defined default state or value representation as a data type. Instantiated subclasses of GM_Object will.
An aggregate class containing only instances of GM_OrientableCurve. The association role “element” shall be the set of GM_OrientableCurves contained in this GM_MultiCurve.
GM_MultiPoint is an aggregate class containing only points. The association role “element” shall be the set of GM_Points contained in this GM_MultiPoint.
An aggregate class containing only instances of GM_OrientableSurface. The association role “element” shall be the set of GM_OrientableSurfaces contained in this GM_MultiSurface.
The attribute “position” shall be the DirectPosition of this GM_Point.
GM_Point::position [1] : DirectPosition
NOTE In most cases, the state of a GM_Point is fully determined by its position attribute. The only exception to this is if the GM_Point has been subclassed to provide additional non-geometric information such as symbology.
Note: Unless otherwise specified, all attribute and role names have the stereotype «Property»
GM_Surface is a subclass of GM_Primitive and is the basis for 2-dimensional geometry. Unorientable surfaces such as the Möbius band are not allowed. The orientation of a surface chooses an “up” direction through the choice of the upward normal, which, if the surface is not a cycle, is the side of the surface from which the exterior boundary appears counterclockwise. Reversal of the surface orientation reverses the curve orientation of each boundary component, and interchanges the conceptual “up” and “down” direction of the surface. If the surface is the boundary of a solid, the “up” direction is usually outward. For closed surfaces, which have no boundary, the up direction is that of the surface patches, which must be consistent with one another. Its included GM_SurfacePatches describe the interior structure of a GM_Surface.
NOTE Other than the restriction on orientability, no other “validity” condition is required for GM_Surface.
A GM_Tin is a GM_TriangulatedSurface that uses the Delaunay algorithm or a similar algorithm complemented with consideration for breaklines, stoplines and maximum length of triangle sides (Figure 22). These networks satisfy the Delaunay criterion away from the modifications: For each triangle in the network, the circle passing through its vertexes does not contain, in its interior, the vertex of any other triangle.
A GM_TriangulatedSurface is a GM_PolyhedralSurface that is composed only of triangles (GM_Triangle). There is no restriction on how the triangulation is derived.
TM_Position is a union class that consists of one of the data types listed as its attributes. Date, Time, and DateTime are basic data types defined in ISO/TS 19103.
Note: Unless otherwise specified, all attribute and role names have the stereotype «Property»
11.2 Core
Table 1176
Description:
The Core module defines the basic components of the CityGML data model. The Core module defines abstract base classes that define the core properties of more specialized thematic classes defined in other modules. The Core module also defines concrete classes that are common to other modules, for example basic data types.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.2.1 Classes
Table 1177
AbstractAppearance
Definition:
AbstractAppearance is the abstract superclass to represent any kind of appearance objects.
Relates generalized representations of the same real-world object in different Levels of Detail to the city object. The direction of this relation is from the city object to the corresponding generalized city objects.
Augments AbstractFeature with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1190
AbstractFeatureWithLifespan
Definition:
AbstractFeatureWithLifespan is the base class for all CityGML features. This class allows the optional specification of the real-world and database times for the existence of each feature.
Augments AbstractFeatureWithLifespan with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1193
AbstractLogicalSpace
Definition:
AbstractLogicalSpace is the abstract superclass for all types of logical spaces. Logical space refers to spaces that are not bounded by physical surfaces but are defined according to thematic considerations.
Augments AbstractLogicalSpace with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1196
AbstractOccupiedSpace
Definition:
AbstractOccupiedSpace is the abstract superclass for all types of physically occupied spaces. Occupied space refers to spaces that are partially or entirely filled with matter.
Augments AbstractOccupiedSpace with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1200
AbstractPhysicalSpace
Definition:
AbstractPhysicalSpace is the abstract superclass for all types of physical spaces. Physical space refers to spaces that are fully or partially bounded by physical objects.
Augments AbstractSpace with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1211
AbstractSpaceBoundary
Definition:
AbstractSpaceBoundary is the abstract superclass for all types of space boundaries. A space boundary is an entity with areal extent in the real world. Space boundaries are objects that bound a Space. They also realize the contact between adjacent spaces.
Augments AbstractThematicSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1218
AbstractUnoccupiedSpace
Definition:
AbstractUnoccupiedSpace is the abstract superclass for all types of physically unoccupied spaces. Unoccupied space refers to spaces that are entirely or mostly free of matter.
Specifies the local engineering coordinate reference system of the CityModel that can be provided inline the CityModel instead of referencing a well-known CRS definition. The definition of an engineering CRS requires an anchor point which relates the origin of the local coordinate system to a point on the earth’s surface in order to facilitate the transformation of coordinates from the local engineering CRS.
Augments the ClosureSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1242
ImplicitGeometry
Definition:
ImplicitGeometry is a geometry representation where the shape is stored only once as a prototypical geometry. Examples are a tree or other vegetation object, a traffic light or a traffic sign. This prototypic geometry object can be re-used or referenced many times, wherever the corresponding feature occurs in the 3D city model.
Specifies the mathematical transformation (translation, rotation, and scaling) between the prototypical geometry and the actual spatial position of the object.
Specifies the URI that points to the prototypical geometry stored in an external file.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.2.2 Data Types
Table 1246
AbstractGenericAttribute
Definition:
AbstractGenericAttribute is the abstract superclass for all types of generic attributes.
Subclass of:
None
Stereotype:
«DataType»
Table 1248
ADEOfAbstractAppearance
Definition:
ADEOfAbstractAppearance acts as a hook to define properties within an ADE that are to be added to AbstractAppearance.
Subclass of:
None
Stereotype:
«DataType»
Table 1250
ADEOfAbstractCityObject
Definition:
ADEOfAbstractCityObject acts as a hook to define properties within an ADE that are to be added to AbstractCityObject.
Subclass of:
None
Stereotype:
«DataType»
Table 1252
ADEOfAbstractDynamizer
Definition:
ADEOfAbstractDynamizer acts as a hook to define properties within an ADE that are to be added to AbstractDynamizer.
Subclass of:
None
Stereotype:
«DataType»
Table 1254
ADEOfAbstractFeature
Definition:
ADEOfAbstractFeature acts as a hook to define properties within an ADE that are to be added to AbstractFeature.
Subclass of:
None
Stereotype:
«DataType»
Table 1256
ADEOfAbstractFeatureWithLifespan
Definition:
ADEOfAbstractFeatureWithLifespan acts as a hook to define properties within an ADE that are to be added to AbstractFeatureWithLifespan.
Subclass of:
None
Stereotype:
«DataType»
Table 1258
ADEOfAbstractLogicalSpace
Definition:
ADEOfAbstractLogicalSpace acts as a hook to define properties within an ADE that are to be added to AbstractLogicalSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1260
ADEOfAbstractOccupiedSpace
Definition:
ADEOfAbstractOccupiedSpace acts as a hook to define properties within an ADE that are to be added to AbstractOccupiedSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1262
ADEOfAbstractPhysicalSpace
Definition:
ADEOfAbstractPhysicalSpace acts as a hook to define properties within an ADE that are to be added to AbstractPhysicalSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1264
ADEOfAbstractPointCloud
Definition:
ADEOfAbstractPointCloud acts as a hook to define properties within an ADE that are to be added to AbstractPointCloud.
Subclass of:
None
Stereotype:
«DataType»
Table 1266
ADEOfAbstractSpace
Definition:
ADEOfAbstractSpace acts as a hook to define properties within an ADE that are to be added to AbstractSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1268
ADEOfAbstractSpaceBoundary
Definition:
ADEOfAbstractSpaceBoundary acts as a hook to define properties within an ADE that are to be added to AbstractSpaceBoundary.
Subclass of:
None
Stereotype:
«DataType»
Table 1270
ADEOfAbstractThematicSurface
Definition:
ADEOfAbstractThematicSurface acts as a hook to define properties within an ADE that are to be added to AbstractThematicSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1272
ADEOfAbstractUnoccupiedSpace
Definition:
ADEOfAbstractUnoccupiedSpace acts as a hook to define properties within an ADE that are to be added to AbstractUnoccupiedSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1274
ADEOfAbstractVersion
Definition:
ADEOfAbstractVersion acts as a hook to define properties within an ADE that are to be added to AbstractVersion.
Subclass of:
None
Stereotype:
«DataType»
Table 1276
ADEOfAbstractVersionTransition
Definition:
ADEOfAbstractVersionTransition acts as a hook to define properties within an ADE that are to be added to AbstractVersionTransition.
Subclass of:
None
Stereotype:
«DataType»
Table 1278
ADEOfAddress
Definition:
ADEOfAddress acts as a hook to define properties within an ADE that are to be added to an Address.
Subclass of:
None
Stereotype:
«DataType»
Table 1280
ADEOfCityModel
Definition:
ADEOfCityModel acts as a hook to define properties within an ADE that are to be added to a CityModel.
Subclass of:
None
Stereotype:
«DataType»
Table 1282
ADEOfClosureSurface
Definition:
ADEOfClosureSurface acts as a hook to define properties within an ADE that are to be added to a ClosureSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1284
ExternalReference
Definition:
ExternalReference is a reference to a corresponding object in another information system, for example in the German cadastre (ALKIS), the German topographic information system (ATKIS), or the OS UK MasterMap®.
Specifies a URI that additionally qualifies the ExternalReference. The URI can point to a definition from an external ontology (e.g. the sameAs relation from OWL) and allows for mapping the ExternalReference to RDF triples.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1287
Occupancy
Definition:
Occupancy is an application-dependent indication of what is contained by a feature.
Associates the Code with an authority that controls the term, keyword, or name.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1301
DoubleBetween0and1
Definition:
DoubleBetween0and1 is a basic type for values, which are greater or equal than 0 and less or equal than 1. The type is used for color encoding, for example.
Subclass of:
None
Stereotype:
«BasicType»
Constraint:
valueBetween0and1 (OCL): inv: DoubleBetween0and1.allInstances() →
forAll(p | p > = 0 and p < = 1)
Table 1303
DoubleBetween0and1List
Definition:
DoubleBetween0and1List is a basic type that represents a list of double values greater or equal than 0 and less or equal than 1. The type is used for color encoding, for example.
Specifies the list of double values and/or nil reasons.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1312
ID
Definition:
ID is a basic type that represents a unique identifier.
Subclass of:
None
Stereotype:
«BasicType»
Table 1314
IntegerBetween0and3
Definition:
IntegerBetween0and3 is a basic type for integer values, which are greater or equal than 0 and less or equal than 3. The type is used for encoding the LOD number.
Subclass of:
None
Stereotype:
«BasicType»
Constraint:
valueBetween0and3 (OCL): inv: IntegerBetween0and3.allInstances() →
forAll(p | p > = 0 and p < = 3)
Table 1316
MeasureOrNilReasonList
Definition:
MeasureOrNilReasonList is a basic type that represents a list of double values and/or nil reasons together with a unit of measurement.
Specifies the feature objects that are part of the CityModel. It allows to include objects that are not derived from a class defined in the CityGML conceptual model, but from the ISO 19109 class AnyFeature.
Table 1328
DoubleOrNilReason
Definition:
DoubleOrNilReason is a union type that allows for choosing between a double value and a nil reason.
Specifies the topic of the Appearance. Each Appearance contains surface data for one theme only. Examples of themes are infrared radiation, noise pollution, or earthquake-induced structural stress.
Augments the Appearance with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1374
GeoreferencedTexture
Definition:
A GeoreferencedTexture is a texture that uses a planimetric projection. It contains an implicit parameterization that is either stored within the image file, an accompanying world file or specified using the orientation and referencePoint elements.
Specifies which interpolation method is used for the shading of the surface geometry object. If the attribute is set to true, vertex normals should be used for shading (Gouraud shading). Otherwise, normals should be constant for a surface patch (flat shading).
Specifies the coordinates of texture used for parameterization. The texture coordinates are provided separately for each LinearRing of the surface geometry object.
lengthOfList (OCL): inv: list→size() = 3 or list→size() = 4
11.3.4 Unions
none
11.3.5 Code Lists
none
11.3.6 Enumerations
Table 1413
TextureType
Definition:
TextureType enumerates the different texture types.
StereoType:
<<Enumeration>>
Literal value
Definition
specific
Indicates that the texture is specific to a single surface.
typical
Indicates that the texture is characteristic of a surface and can be used repeatedly.
unknown
Indicates that the texture type is not known.
Table 1416
WrapMode
Definition:
WrapMode enumerates the different fill modes for textures.
StereoType:
<<Enumeration>>
Literal value
Definition
none
Indicates that the texture is applied to the surface “as is”. The part of the surface that is not covered by the texture is shown fully transparent. [cf. COLLADA]
wrap
Indicates that the texture is repeated until the surface is fully covered. [cf. COLLADA]
mirror
Indicates that the texture is repeated and mirrored. [cf. COLLADA]
clamp
Indicates that the texture is stretched to the edges of the surface. [cf. COLLADA]
border
Indicates that the texture is applied to the surface “as is”. The part of the surface that is not covered by the texture is filled with the RGBA color that is specified in the attribute borderColor. [cf. COLLADA]
11.4 CityFurniture
Table 1419
Description:
The CityFurniture module supports representation of city furniture objects. City furniture objects are immovable objects like lanterns, traffic signs, advertising columns, benches, or bus stops that can be found in traffic areas, residential areas, on squares, or in built-up areas.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.4.1 Classes
Table 1420
CityFurniture
Definition:
CityFurniture is an object or piece of equipment installed in the outdoor environment for various purposes. Examples include street signs, traffic signals, street lamps, benches, fountains.
Augments the CityFurniture with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.4.2 Data Types
Table 1423
ADEOfCityFurniture
Definition:
ADEOfCityFurniture acts as a hook to define properties within an ADE that are to be added to a CityFurniture.
Subclass of:
None
Stereotype:
«DataType»
11.4.3 Basic Types
none
11.4.4 Unions
none
11.4.5 Code Lists
Table 1425
CityFurnitureClassValue
Definition:
CityFurnitureClassValue is a code list used to further classify a CityFurniture.
Stereotype:
«CodeList»
Table 1427
CityFurnitureFunctionValue
Definition:
CityFurnitureFunctionValue is a code list that enumerates the different purposes of a CityFurniture.
Stereotype:
«CodeList»
Table 1429
CityFurnitureUsageValue
Definition:
CityFurnitureUsageValue is a code list that enumerates the different uses of a CityFurniture.
Stereotype:
«CodeList»
11.4.6 Enumerations
none
11.5 CityObjectGroup
Table 1431
Description:
The CityObjectGroup module supports grouping of city objects. Arbitrary city objects may be aggregated in groups according to user-defined criteria. A group may be further classified by application-specific attributes.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.5.1 Classes
Table 1432
CityObjectGroup
Definition:
A CityObjectGroup represents an application-specific aggregation of city objects according to some user-defined criteria. Examples for groups are the buildings in a specific region, the result of a query, or objects put together for visualization purposes. Each member of a group may be qualified by a role name, reflecting the role each city object plays in the context of the group.
Describes the role the city object plays within the CityObjectGroup.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.5.2 Data Types
Table 1439
ADEOfCityObjectGroup
Definition:
ADEOfCityObjectGroup acts as a hook to define properties within an ADE that are to be added to a CityObjectGroup.
Subclass of:
None
Stereotype:
«DataType»
11.5.3 Basic Types
none
11.5.4 Unions
none
11.5.5 Code Lists
Table 1441
CityObjectGroupClassValue
Definition:
CityObjectGroupClassValue is a code list used to further classify a CityObjectGroup.
Stereotype:
«CodeList»
Table 1443
CityObjectGroupFunctionValue
Definition:
CityObjectGroupFunctionValue is a code list that enumerates the different purposes of a CityObjectGroup.
Stereotype:
«CodeList»
Table 1445
CityObjectGroupUsageValue
Definition:
CityObjectGroupUsageValue is a code list that enumerates the different uses of a CityObjectGroup.
Stereotype:
«CodeList»
11.5.6 Enumerations
none
11.6 Dynamizer
Table 1447
Description:
The Dynamizer module supports the injection of timeseries data for individual attributes of CityGML features. Timeseries data can either be retrieved from external Sensor APIs (e.g. OGC SensorThings API, OGC Sensor Observation Services, MQTT, proprietary platforms), external standardized timeseries files (e.g. OGC TimeseriesML or OGC Observations & Measurements), external tabulated files (e.g CSV) or can be represented inline as basic time-value pairs.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.6.1 Classes
Table 1448
AbstractAtomicTimeseries
Definition:
AbstractAtomicTimeseries represents the attributes and relationships that are common to all kinds of atomic timeseries (GenericTimeseries, TabulatedFileTimeseries, StandardFileTimeseries). An atomic timeseries represents time-varying data of a specific data type for a single contiguous time interval.
Augments AbstractTimeseries with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1454
CompositeTimeseries
Definition:
A CompositeTimeseries is a (possibly recursive) aggregation of atomic and composite timeseries. The components of a composite timeseries must have non-overlapping time intervals.
Augments the CompositeTimeseries with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1458
Dynamizer
Definition:
A Dynamizer is an object that injects timeseries data for an individual attribute of the city object in which it is included. The timeseries data overrides the static value of the referenced city object attribute in order to represent dynamic (time-dependent) variations of its value.
Augments the Dynamizer with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1462
GenericTimeseries
Definition:
A GenericTimeseries represents time-varying data in the form of embedded time-value-pairs of a specific data type for a single contiguous time interval.
dataTypeOfValue (OCL): inv:
if valueType = TimeseriesTypeValue::integer then
TimeValuePair→forAll(c | c.intValue→size()=1)
else if valueType = TimeseriesTypeValue::double then
TimeValuePair→forAll(c | c.doubleValue→size()=1)
else if valueType = TimeseriesTypeValue::string then
TimeValuePair→forAll(c | c.stringValue→size()=1)
else if valueType = TimeseriesTypeValue::geometry then
TimeValuePair→forAll(c | c.geometryValue→size()=1)
else if valueType = TimeseriesTypeValue::uri then
TimeValuePair→forAll(c | c.uriValue→size()=1)
else if valueType = TimeseriesTypeValue::bool then
TimeValuePair→forAll(c | c.boolValue→size()=1)
else if valueType = TimeseriesTypeValue::implicitGeometry then
TimeValuePair→forAll(c | c.implicitGeometryValue→size()=1)
else TimeValuePair→forAll(c | c.appearanceValue→size()=1)
Augments the GenericTimeseries with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1466
StandardFileTimeseries
Definition:
A StandardFileTimeseries represents time-varying data for a single contiguous time interval. The data is provided in an external file referenced in the StandardFileTimeseries. The data within the external file is encoded according to a dedicated format for the representation of timeseries data such as using the OGC TimeseriesML or OGC Observations & Measurements Standard. The data type of the data has to be specified within the external file.
Augments the StandardFileTimeseries with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1469
TabulatedFileTimeseries
Definition:
A TabulatedFileTimeseries represents time-varying data of a specific data type for a single contiguous time interval. The data is provided in an external file referenced in the TabulatedFileTimeseries. The file contains table structured data using an appropriate file format such as comma-separated values (CSV), Microsoft Excel (XLSX) or Google Spreadsheet. The timestamps and the values are given in specific columns of the table. Each row represents a single time-value-pair. A subset of rows can be selected using the idColumn and idValue attributes.
columnNumberOrColumnName (OCL): inv:
(timeColumnNo→notEmpty() or timeColumnName→notEmpty()) and
(valueColumnNo→notEmpty() or valueColumnName→notEmpty()) and
(idValue→notEmpty() implies idColumnNo→notEmpty() or + idColumnName→notEmpty())
Augments the TabulatedFileTimeseries with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.6.2 Data Types
Table 1472
ADEOfAbstractAtomicTimeseries
Definition:
ADEOfAbstractAtomicTimeseries acts as a hook to define properties within an ADE that are to be added to AbstractAtomicTimeseries.
Subclass of:
None
Stereotype:
«DataType»
Table 1474
ADEOfAbstractTimeseries
Definition:
ADEOfAbstractTimeseries acts as a hook to define properties within an ADE that are to be added to AbstractTimeseries.
Subclass of:
None
Stereotype:
«DataType»
Table 1476
ADEOfCompositeTimeseries
Definition:
ADEOfCompositeTimeseries acts as a hook to define properties within an ADE that are to be added to a CompositeTimeseries.
Subclass of:
None
Stereotype:
«DataType»
Table 1478
ADEOfDynamizer
Definition:
ADEOfDynamizer acts as a hook to define properties within an ADE that are to be added to a Dynamizer.
Subclass of:
None
Stereotype:
«DataType»
Table 1480
ADEOfGenericTimeseries
Definition:
ADEOfGenericTimeseries acts as a hook to define properties within an ADE that are to be added to a GenericTimeseries.
Subclass of:
None
Stereotype:
«DataType»
Table 1482
ADEOfStandardFileTimeseries
Definition:
ADEOfStandardFileTimeseries acts as a hook to define properties within an ADE that are to be added to a StandardFileTimeseries.
Subclass of:
None
Stereotype:
«DataType»
Table 1484
ADEOfTabulatedFileTimeseries
Definition:
ADEOfTabulatedFileTimeseries acts as a hook to define properties within an ADE that are to be added to a TabulatedFileTimeseries.
Subclass of:
None
Stereotype:
«DataType»
Table 1486
SensorConnection
Definition:
A SensorConnection provides all details that are required to retrieve a specific datastream from an external sensor web service. This data type comprises the service type (e.g. OGC SensorThings API, OGC Sensor Observation Services, MQTT, proprietary platforms), the URL of the sensor service, the identifier for the sensor or thing, and its observed property as well as information about the required authentication method.
Names the specific datastream that is retrieved by the SensorConnection. This attribute is relevant when the MQTT Protocol is used to connect to a Sensor API.
Specifies how much extra time is added after all repetitions as an additional gap.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1494
TimeValuePair
Definition:
A TimeValuePair represents a value that is valid for a given timepoint. For each TimeValuePair, only one of the value properties can be used mutually exclusive. Which value property has to be provided depends on the selected value type in the GenericTimeSeries feature, in which the TimeValuePair is included.
Specifies the “Appearance” value of the TimeValuePair.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.6.3 Basic Types
none
11.6.4 Unions
none
11.6.5 Code Lists
Table 1497
AuthenticationTypeValue
Definition:
AuthenticationTypeValue is a code list used to specify the authentication method to be used to access the referenced sensor service. Each value provides enough information such that a software application could determine the required access credentials.
Stereotype:
«CodeList»
Table 1499
SensorConnectionTypeValue
Definition:
SensorConnectionTypeValue is a code list used to specify the type of the referenced sensor service. Each value provides enough information such that a software application would be able to identify the API type and version.
Stereotype:
«CodeList»
Table 1501
StandardFileTypeValue
Definition:
StandardFileTypeValue is a code list used to specify the type of the referenced external timeseries data file. Each value provides information about the standard and version.
Stereotype:
«CodeList»
Table 1503
TabulatedFileTypeValue
Definition:
TabulatedFileTypeValue is a code list used to specify the data format of the referenced external tabulated data file.
Stereotype:
«CodeList»
11.6.6 Enumerations
Table 1505
TimeseriesTypeValue
Definition:
TimeseriesTypeValue enumerates the possible value types for GenericTimeseries and TimeValuePair.
StereoType:
<<Enumeration>>
Literal value
Definition
int
Indicates that the values of the GenericTimeseries are of type “Integer”.
double
Indicates that the values of the GenericTimeseries are of type “Double”.
string
Indicates that the values of the GenericTimeseries are of type “String”.
geometry
Indicates that the values of the GenericTimeseries are geometries.
uri
Indicates that the values of the GenericTimeseries are of type “URI”.
bool
Indicates that the values of the GenericTimeseries are of type “Boolean”.
implicitGeometry
Indicates that the values of the GenericTimeseries are of type “ImplicitGeometry”.
appearance
Indicates that the values of the GenericTimeseries are of type “Appearance”.
11.7 Generics
Table 1508
Description:
The Generics module supports application-specific extensions to the CityGML data model. These extensions may be used to model and exchange additional attributes and features not covered by the predefined thematic classes of CityGML. Generic extensions shall only be used if appropriate thematic classes or attributes are not provided by any other CityGML module.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.7.1 Classes
Table 1509
GenericLogicalSpace
Definition:
A GenericLogicalSpace is a space that is not represented by any explicitly modelled AbstractLogicalSpace subclass within CityGML.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.7.3 Basic Types
none
11.7.4 Unions
none
11.7.5 Code Lists
Table 1554
GenericLogicalSpaceClassValue
Definition:
GenericLogicalSpaceClassValue is a code list used to further classify a GenericLogicalSpace.
Stereotype:
«CodeList»
Table 1556
GenericLogicalSpaceFunctionValue
Definition:
GenericLogicalSpaceFunctionValue is a code list that enumerates the different purposes of a GenericLogicalSpace.
Stereotype:
«CodeList»
Table 1558
GenericLogicalSpaceUsageValue
Definition:
GenericLogicalSpaceUsageValue is a code list that enumerates the different uses of a GenericLogicalSpace.
Stereotype:
«CodeList»
Table 1560
GenericOccupiedSpaceClassValue
Definition:
GenericOccupiedSpaceClassValue is a code list used to further classify a GenericOccupiedSpace.
Stereotype:
«CodeList»
Table 1562
GenericOccupiedSpaceFunctionValue
Definition:
GenericOccupiedSpaceFunctionValue is a code list that enumerates the different purposes of a GenericOccupiedSpace.
Stereotype:
«CodeList»
Table 1564
GenericOccupiedSpaceUsageValue
Definition:
GenericOccupiedSpaceUsageValue is a code list that enumerates the different uses of a GenericOccupiedSpace.
Stereotype:
«CodeList»
Table 1566
GenericThematicSurfaceClassValue
Definition:
GenericThematicSurfaceClassValue is a code list used to further classify a GenericThematicSurface.
Stereotype:
«CodeList»
Table 1568
GenericThematicSurfaceFunctionValue
Definition:
GenericThematicSurfaceFunctionValue is a code list that enumerates the different purposes of a GenericThematicSurface.
Stereotype:
«CodeList»
Table 1570
GenericThematicSurfaceUsageValue
Definition:
GenericThematicSurfaceUsageValue is a code list that enumerates the different uses of a GenericThematicSurface.
Stereotype:
«CodeList»
Table 1572
GenericUnoccupiedSpaceClassValue
Definition:
GenericUnoccupiedSpaceClassValue is a code list used to further classify a GenericUnoccupiedSpace.
Stereotype:
«CodeList»
Table 1574
GenericUnoccupiedSpaceFunctionValue
Definition:
GenericUnoccupiedSpaceFunctionValue is a code list that enumerates the different purposes of a GenericUnoccupiedSpace.
Stereotype:
«CodeList»
Table 1576
GenericUnoccupiedSpaceUsageValue
Definition:
GenericUnoccupiedSpaceUsageValue is a code list that enumerates the different uses of a GenericUnoccupiedSpace.
Stereotype:
«CodeList»
11.7.6 Enumerations
none
11.8 LandUse
Table 1578
Description:
The LandUse module supports representation of areas of the earth’s surface dedicated to a specific land use.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.8.1 Classes
Table 1579
LandUse
Definition:
A LandUse object is an area of the earth’s surface dedicated to a specific land use or having a specific land cover with or without vegetation, such as sand, rock, mud flats, forest, grasslands, or wetlands.
inlineOrExternalPointCloud (OCL): inv: (points→notEmpty() and mimeType→isEmpty() and pointFile→isEmpty() and pointFileSrsName→isEmpty()) xor (points→isEmpty() and mimeType→notEmpty() and pointFile→notEmpty())
Augments the PointCloud with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.9.2 Data Types
Table 1595
ADEOfPointCloud
Definition:
ADEOfPointCloud acts as a hook to define properties within an ADE that are to be added to a PointCloud.
Subclass of:
None
Stereotype:
«DataType»
11.9.3 Basic Types
none
11.9.4 Unions
none
11.9.5 Code Lists
none
11.9.6 Enumerations
none
11.10 Relief
Table 1597
Description:
The Relief module supports representation of the terrain. CityGML supports terrain representations at different levels of detail, reflecting different accuracies or resolutions. Terrain may be specified as a regular raster or grid, as a TIN, by break lines, and/or by mass points.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.10.1 Classes
Table 1598
AbstractReliefComponent
Definition:
An AbstractReliefComponent represents an element of the terrain surface — either a TIN, a raster or grid, mass points or break lines.
Augments the TINRelief with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.10.2 Data Types
Table 1622
ADEOfAbstractReliefComponent
Definition:
ADEOfAbstractReliefComponent acts as a hook to define properties within an ADE that are to be added to AbstractReliefComponent.
Subclass of:
None
Stereotype:
«DataType»
Table 1624
ADEOfBreaklineRelief
Definition:
ADEOfBreaklineRelief acts as a hook to define properties within an ADE that are to be added to a BreaklineRelief.
Subclass of:
None
Stereotype:
«DataType»
Table 1626
ADEOfMassPointRelief
Definition:
ADEOfMassPointRelief acts as a hook to define properties within an ADE that are to be added to a MassPointRelief.
Subclass of:
None
Stereotype:
«DataType»
Table 1628
ADEOfRasterRelief
Definition:
ADEOfRasterRelief acts as a hook to define properties within an ADE that are to be added to a RasterRelief.
Subclass of:
None
Stereotype:
«DataType»
Table 1630
ADEOfReliefFeature
Definition:
ADEOfReliefFeature acts as a hook to define properties within an ADE that are to be added to a ReliefFeature.
Subclass of:
None
Stereotype:
«DataType»
Table 1632
ADEOfTINRelief
Definition:
ADEOfTINRelief acts as a hook to define properties within an ADE that are to be added to a TINRelief.
Subclass of:
None
Stereotype:
«DataType»
11.10.3 Basic Types
none
11.10.4 Unions
none
11.10.5 Code Lists
none
11.10.6 Enumerations
none
11.11 Transportation
Table 1634
Description:
The Transportation module supports representation of the transportation infrastructure. Transportation features include roads, tracks, waterways, railways, and squares. Transportation features may be represented as a network and/or as a collection of spaces or surface elements embedded in a three-dimensional space.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.11.1 Classes
Table 1635
AbstractTransportationSpace
Definition:
AbstractTransportationSpace is the abstract superclass of transportation objects such as Roads, Tracks, Railways, Waterways or Squares.
Defines whether auxiliary traffic spaces are represented by individual ways or by individual lanes, depending on the desired level of spatial and semantic decomposition.
Augments the ClearanceSpace with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1649
Hole
Definition:
A Hole is an opening in the surface of a Road, Track or Square such as road damages, manholes or drains. Holes can span multiple transportation objects.
Augments the HoleSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1656
Intersection
Definition:
An Intersection is a transportation space that is a shared segment of multiple Road, Track, Railway, or Waterway objects (e.g. a crossing of two roads or a level crossing of a road and a railway).
Augments the Intersection with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1659
Marking
Definition:
A Marking is a visible pattern on a transportation area relevant to the structuring or restriction of traffic. Examples are road markings and markings related to railway or waterway traffic.
Augments the Section with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1673
Square
Definition:
A Square is a transportation space for unrestricted movement for vehicles, bicycles and/or pedestrians. This includes plazas as well as large sealed surfaces such as parking lots.
Augments the TrafficArea with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1683
TrafficSpace
Definition:
A TrafficSpace is a space in which traffic takes place. Traffic includes the movement of entities such as trains, vehicles, pedestrians, ships, or other transportation types.
Defines whether traffic spaces are represented by individual ways or by individual lanes, depending on the desired level of spatial and semantic decomposition.
Augments the Waterway with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.11.2 Data Types
Table 1691
ADEOfAbstractTransportationSpace
Definition:
ADEOfAbstractTransportationSpace acts as a hook to define properties within an ADE that are to be added to AbstractTransportationSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1693
ADEOfAuxiliaryTrafficArea
Definition:
ADEOfAuxiliaryTrafficArea acts as a hook to define properties within an ADE that are to be added to an AuxiliaryTrafficArea.
Subclass of:
None
Stereotype:
«DataType»
Table 1695
ADEOfAuxiliaryTrafficSpace
Definition:
ADEOfAuxiliaryTrafficSpace acts as a hook to define properties within an ADE that are to be added to an AuxiliaryTrafficSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1697
ADEOfClearanceSpace
Definition:
ADEOfClearanceSpace acts as a hook to define properties within an ADE that are to be added to a ClearanceSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1699
ADEOfHole
Definition:
ADEOfHole acts as a hook to define properties within an ADE that are to be added to a Hole.
Subclass of:
None
Stereotype:
«DataType»
Table 1701
ADEOfHoleSurface
Definition:
ADEOfHoleSurface acts as a hook to define properties within an ADE that are to be added to a HoleSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1703
ADEOfIntersection
Definition:
ADEOfIntersection acts as a hook to define properties within an ADE that are to be added to an Intersection.
Subclass of:
None
Stereotype:
«DataType»
Table 1705
ADEOfMarking
Definition:
ADEOfMarking acts as a hook to define properties within an ADE that are to be added to a Marking.
Subclass of:
None
Stereotype:
«DataType»
Table 1707
ADEOfRailway
Definition:
ADEOfRailway acts as a hook to define properties within an ADE that are to be added to a Railway.
Subclass of:
None
Stereotype:
«DataType»
Table 1709
ADEOfRoad
Definition:
ADEOfRoad acts as a hook to define properties within an ADE that are to be added to a Road.
Subclass of:
None
Stereotype:
«DataType»
Table 1711
ADEOfSection
Definition:
ADEOfSection acts as a hook to define properties within an ADE that are to be added to a Section.
Subclass of:
None
Stereotype:
«DataType»
Table 1713
ADEOfSquare
Definition:
ADEOfSquare acts as a hook to define properties within an ADE that are to be added to a Square.
Subclass of:
None
Stereotype:
«DataType»
Table 1715
ADEOfTrack
Definition:
ADEOfTrack acts as a hook to define properties within an ADE that are to be added to a Track.
Subclass of:
None
Stereotype:
«DataType»
Table 1717
ADEOfTrafficArea
Definition:
ADEOfTrafficArea acts as a hook to define properties within an ADE that are to be added to a TrafficArea.
Subclass of:
None
Stereotype:
«DataType»
Table 1719
ADEOfTrafficSpace
Definition:
ADEOfTrafficSpace acts as a hook to define properties within an ADE that are to be added to a TrafficSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 1721
ADEOfWaterway
Definition:
ADEOfWaterway acts as a hook to define properties within an ADE that are to be added to a Waterway.
Subclass of:
None
Stereotype:
«DataType»
11.11.3 Basic Types
none
11.11.4 Unions
none
11.11.5 Code Lists
Table 1723
AuxiliaryTrafficAreaClassValue
Definition:
AuxiliaryTrafficAreaClassValue is a code list used to further classify an AuxiliaryTrafficArea.
Stereotype:
«CodeList»
Table 1725
AuxiliaryTrafficAreaFunctionValue
Definition:
AuxiliaryTrafficAreaFunctionValue is a code list that enumerates the different purposes of an AuxiliaryTrafficArea.
Stereotype:
«CodeList»
Table 1727
AuxiliaryTrafficAreaUsageValue
Definition:
AuxiliaryTrafficAreaUsageValue is a code list that enumerates the different uses of an AuxiliaryTrafficArea.
Stereotype:
«CodeList»
Table 1729
AuxiliaryTrafficSpaceClassValue
Definition:
AuxiliaryTrafficSpaceClassValue is a code list used to further classify an AuxiliaryTrafficSpace.
Stereotype:
«CodeList»
Table 1731
AuxiliaryTrafficSpaceFunctionValue
Definition:
AuxiliaryTrafficSpaceFunctionValue is a code list that enumerates the different purposes of an AuxiliaryTrafficSpace.
Stereotype:
«CodeList»
Table 1733
AuxiliaryTrafficSpaceUsageValue
Definition:
AuxiliaryTrafficSpaceUsageValue is a code list that enumerates the different uses of an AuxiliaryTrafficSpace.
Stereotype:
«CodeList»
Table 1735
ClearanceSpaceClassValue
Definition:
ClearanceSpaceClassValue is a code list used to further classify a ClearanceSpace.
Stereotype:
«CodeList»
Table 1737
HoleClassValue
Definition:
HoleClassValue is a code list used to further classify a Hole.
Stereotype:
«CodeList»
Table 1739
IntersectionClassValue
Definition:
IntersectionClassValue is a code list used to further classify an Intersection.
Stereotype:
«CodeList»
Table 1741
MarkingClassValue
Definition:
MarkingClassValue is a code list used to further classify a Marking.
Stereotype:
«CodeList»
Table 1743
RailwayClassValue
Definition:
RailwayClassValue is a code list used to further classify a Railway.
Stereotype:
«CodeList»
Table 1745
RailwayFunctionValue
Definition:
RailwayFunctionValue is a code list that enumerates the different purposes of a Railway.
Stereotype:
«CodeList»
Table 1747
RailwayUsageValue
Definition:
RailwayUsageValue is a code list that enumerates the different uses of a Railway.
Stereotype:
«CodeList»
Table 1749
RoadClassValue
Definition:
RoadClassValue is a code list used to further classify a Road.
Stereotype:
«CodeList»
Table 1751
RoadFunctionValue
Definition:
RoadFunctionValue is a code list that enumerates the different purposes of a Road.
Stereotype:
«CodeList»
Table 1753
RoadUsageValue
Definition:
RoadUsageValue is a code list that enumerates the different uses of a Road.
Stereotype:
«CodeList»
Table 1755
SectionClassValue
Definition:
SectionClassValue is a code list used to further classify a Section.
Stereotype:
«CodeList»
Table 1757
SquareClassValue
Definition:
SquareClassValue is a code list used to further classify a Square.
Stereotype:
«CodeList»
Table 1759
SquareFunctionValue
Definition:
SquareFunctionValue is a code list that enumerates the different purposes of a Square.
Stereotype:
«CodeList»
Table 1761
SquareUsageValue
Definition:
SquareUsageValue is a code list that enumerates the different uses of a Square.
Stereotype:
«CodeList»
Table 1763
SurfaceMaterialValue
Definition:
SurfaceMaterialValue is a code list that enumerates the different surface materials.
Stereotype:
«CodeList»
Table 1765
TrackClassValue
Definition:
TrackClassValue is a code list used to further classify a Track.
Stereotype:
«CodeList»
Table 1767
TrackFunctionValue
Definition:
TrackFunctionValue is a code list that enumerates the different purposes of a Track.
Stereotype:
«CodeList»
Table 1769
TrackUsageValue
Definition:
TrackUsageValue is a code list that enumerates the different uses of a Track.
Stereotype:
«CodeList»
Table 1771
TrafficAreaClassValue
Definition:
TrafficAreaClassValue is a code list used to further classify a TrafficArea.
Stereotype:
«CodeList»
Table 1773
TrafficAreaFunctionValue
Definition:
TrafficAreaFunctionValue is a code list that enumerates the different purposes of a TrafficArea.
Stereotype:
«CodeList»
Table 1775
TrafficAreaUsageValue
Definition:
TrafficAreaUsageValue is a code list that enumerates the different uses of a TrafficArea.
Stereotype:
«CodeList»
Table 1777
TrafficSpaceClassValue
Definition:
TrafficSpaceClassValue is a code list used to further classify a TrafficSpace.
Stereotype:
«CodeList»
Table 1779
TrafficSpaceFunctionValue
Definition:
TrafficSpaceFunctionValue is a code list that enumerates the different purposes of a TrafficSpace.
Stereotype:
«CodeList»
Table 1781
TrafficSpaceUsageValue
Definition:
TrafficSpaceUsageValue is a code list that enumerates the different uses of a TrafficSpace.
Stereotype:
«CodeList»
Table 1783
WaterwayClassValue
Definition:
WaterwayClassValue is a code list used to further classify a Waterway.
Stereotype:
«CodeList»
Table 1785
WaterwayFunctionValue
Definition:
WaterwayFunctionValue is a code list that enumerates the different purposes of a Waterway.
Stereotype:
«CodeList»
Table 1787
WaterwayUsageValue
Definition:
WaterwayUsageValue is a code list that enumerates the different uses of a Waterway.
Stereotype:
«CodeList»
11.11.6 Enumerations
Table 1789
GranularityValue
Definition:
GranularityValue enumerates the different levels of granularity in which transportation objects are represented.
StereoType:
<<Enumeration>>
Literal value
Definition
lane
Indicates that the individual lanes of the transportation object are represented.
way
Indicates that the individual (carriage)ways of the transportation object are represented.
Table 1792
TrafficDirectionValue
Definition:
TrafficDirectionValue enumerates the allowed directions of travel of a mobile object.
StereoType:
<<Enumeration>>
Literal value
Definition
forwards
Indicates that traffic flows in the direction of the corresponding linear geometry.
backwards
Indicates that traffic flows in the opposite direction of the corresponding linear geometry.
both
Indicates that traffic flows in both directions.
11.12 Vegetation
Table 1795
Description:
The Vegetation module supports representation of vegetation objects with vegetation-specific thematic classes. CityGML’s vegetation model distinguishes between solitary vegetation objects like trees, and vegetation areas which represent biotopes like forests or other plant communities.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.12.1 Classes
Table 1796
AbstractVegetationObject
Definition:
AbstractVegetationObject is the abstract superclass for all kinds of vegetation objects.
Augments the SolitaryVegetationObject with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.12.2 Data Types
Table 1805
ADEOfAbstractVegetationObject
Definition:
ADEOfAbstractVegetationObject acts as a hook to define properties within an ADE that are to be added to AbstractVegetationObject.
Subclass of:
None
Stereotype:
«DataType»
Table 1807
ADEOfPlantCover
Definition:
ADEOfPlantCover acts as a hook to define properties within an ADE that are to be added to a PlantCover.
Subclass of:
None
Stereotype:
«DataType»
Table 1809
ADEOfSolitaryVegetationObject
Definition:
ADEOfSolitaryVegetationObject acts as a hook to define properties within an ADE that are to be added to a SolitaryVegetationObject.
Subclass of:
None
Stereotype:
«DataType»
11.12.3 Basic Types
none
11.12.4 Unions
none
11.12.5 Code Lists
Table 1811
PlantCoverClassValue
Definition:
PlantCoverClassValue is a code list used to further classify a PlantCover.
Stereotype:
«CodeList»
Table 1813
PlantCoverFunctionValue
Definition:
PlantCoverFunctionValue is a code list that enumerates the different purposes of a PlantCover.
Stereotype:
«CodeList»
Table 1815
PlantCoverUsageValue
Definition:
PlantCoverUsageValue is a code list that enumerates the different uses of a PlantCover.
Stereotype:
«CodeList»
Table 1817
SolitaryVegetationObjectClassValue
Definition:
SolitaryVegetationObjectClassValue is a code list used to further classify a SolitaryVegetationObject.
Stereotype:
«CodeList»
Table 1819
SolitaryVegetationObjectFunctionValue
Definition:
SolitaryVegetationObjectFunctionValue is a code list that enumerates the different purposes of a SolitaryVegetationObject.
Stereotype:
«CodeList»
Table 1821
SolitaryVegetationObjectUsageValue
Definition:
SolitaryVegetationObjectUsageValue is a code list that enumerates the different uses of a SolitaryVegetationObject.
Stereotype:
«CodeList»
Table 1823
SpeciesValue
Definition:
A SpeciesValue is a code list that enumerates the species of a SolitaryVegetationObject.
Stereotype:
«CodeList»
11.12.6 Enumerations
none
11.13 Versioning
Table 1825
Description:
The Versioning module supports representation of multiple versions of CityGML features within a single CityGML model. In addition, also the version transitions and transactions that lead to the different versions can be represented.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.13.1 Classes
Table 1826
Version
Definition:
Version represents a defined state of a city model consisting of the dedicated versions of all city object instances that belong to the respective city model version. Versions can have names, a description and can be labeled with an arbitrary number of user defined tags.
Augments the Version with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1830
VersionTransition
Definition:
VersionTransition describes the change of the state of a city model from one version to another. Version transitions can have names, a description and can be further qualified by a type and a reason.
Indicates whether the set of city object instances belonging to the successor version of the city model is either explicitly enumerated within the successor version object (attribute clonePredecessor=false), or has to be derived from the modifications of the city model provided as a list of transactions on the city object versions contained in the predecessor version (attribute clonePredecessor=true).
Augments the VersionTransition with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.13.2 Data Types
Table 1834
ADEOfVersion
Definition:
ADEOfVersion acts as a hook to define properties within an ADE that are to be added to a Version.
Subclass of:
None
Stereotype:
«DataType»
Table 1836
ADEOfVersionTransition
Definition:
ADEOfVersionTransition acts as a hook to define properties within an ADE that are to be added to a VersionTransition.
Subclass of:
None
Stereotype:
«DataType»
Table 1838
Transaction
Definition:
Transaction represents a modification of the city model by the creation, termination, or replacement of a specific city object. While the creation of a city object also marks its first object version, the termination marks the end of existence of a real world object and, hence, also terminates the final version of a city object. The replacement of a city object means that a specific version of it is replaced by a new version.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.13.3 Basic Types
none
11.13.4 Unions
none
11.13.5 Code Lists
none
11.13.6 Enumerations
Table 1842
TransactionTypeValue
Definition:
TransactionTypeValue enumerates the three possible types of transactions: insert, delete, or replace.
StereoType:
<<Enumeration>>
Literal value
Definition
insert
Indicates that the feature referenced from the Transaction via the “newFeature” association has been newly created; the association “oldFeature” is empty in this case.
delete
Indicates that the feature referenced from the Transaction via the “oldFeature” association ceases to exist; the association “newFeature” is empty in this case.
replace
Indicates that the feature referenced from the Transaction via the “oldFeature” association has been replaced by the feature referenced via the “newFeature” association.
Table 1845
TransitionTypeValue
Definition:
TransitionTypeValue enumerates the different kinds of version transitions. “planned” and “fork” should be used in cases when from one city model version multiple successor versions are being created. “realized” and “merge” should be used when different city model versions are converging into a common successor version.
StereoType:
<<Enumeration>>
Literal value
Definition
planned
Indicates that the successor version of the city model represents a planning state for a possible future of the city.
realized
Indicates that the predecessor version is the chosen one from a number of possible planning versions.
historicalSuccession
Indicates that the successor version reflects updates on the city model over time (historical timeline). It shall only be used for at most one version transition outgoing from a city model version.
fork
Indicates other reasons to create alternative city model versions, for example, when different parties are updating parts of the city model or to reflect the results of different simulation runs.
merge
Indicates other reasons to converge multiple versions back into a common city model version.
11.14 WaterBody
Table 1848
Description:
The WaterBody module supports representation of the thematic aspects and 3D geometry of rivers, canals, lakes, and basins. It does, however, not inherit any hydrological or other dynamic aspects of fluid flow.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.14.1 Classes
Table 1849
AbstractWaterBoundarySurface
Definition:
AbstractWaterBoundarySurface is the abstract superclass for all kinds of thematic surfaces bounding a water body.
Augments the WaterSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.14.2 Data Types
Table 1862
ADEOfAbstractWaterBoundarySurface
Definition:
ADEOfAbstractWaterBoundarySurface acts as a hook to define properties within an ADE that are to be added to AbstractWaterBoundarySurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1864
ADEOfWaterBody
Definition:
ADEOfWaterBody acts as a hook to define properties within an ADE that are to be added to a WaterBody.
Subclass of:
None
Stereotype:
«DataType»
Table 1866
ADEOfWaterGroundSurface
Definition:
ADEOfWaterGroundSurface acts as a hook to define properties within an ADE that are to be added to a WaterGroundSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1868
ADEOfWaterSurface
Definition:
ADEOfWaterSurface acts as a hook to define properties within an ADE that are to be added to a WaterSurface.
Subclass of:
None
Stereotype:
«DataType»
11.14.3 Basic Types
none
11.14.4 Unions
none
11.14.5 Code Lists
Table 1870
WaterBodyClassValue
Definition:
WaterBodyClassValue is a code list used to further classify a WaterBody.
Stereotype:
«CodeList»
Table 1872
WaterBodyFunctionValue
Definition:
WaterBodyFunctionValue is a code list that enumerates the different purposes of a WaterBody.
Stereotype:
«CodeList»
Table 1874
WaterBodyUsageValue
Definition:
WaterBodyUsageValue is a code list that enumerates the different uses of a WaterBody.
Stereotype:
«CodeList»
Table 1876
WaterLevelValue
Definition:
WaterLevelValue is a code list that enumerates the different levels of a water surface.
Stereotype:
«CodeList»
11.14.6 Enumerations
none
11.15 Construction
Table 1878
Description:
The Construction module supports representation of key elements of different types of constructions. These key elements include construction surfaces (e.g floor and ceiling), windows and doors, constructive elements (e.g. beams and slabs), installations, and furniture.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.15.1 Classes
Table 1879
AbstractConstruction
Definition:
AbstractConstruction is the abstract superclass for objects that are manufactured by humans from construction materials, are connected to earth, and are intended to be permanent. A connection with the ground also exists when the construction rests by its own weight on the ground or is moveable limited on stationary rails or if the construction is intended to be used mainly stationary.
Specifies qualified elevations of the construction in relation to a well-defined surface which is commonly taken as origin (e.g. geoid or water level). [cf. INSPIRE]
Augments AbstractConstructionSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1887
AbstractConstructiveElement
Definition:
AbstractConstructiveElement is the abstract superclass for the representation of volumetric elements of a construction. Examples are walls, beams, slabs.
Indicates whether the constructive element is essential from a structural point of view. A structural element cannot be omitted without collapsing of the construction. Examples are pylons and anchorages of bridges.
Augments the FloorSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1918
GroundSurface
Definition:
A GroundSurface is a surface that represents the ground plate of a construction. The polygon defining the ground plate is congruent with the footprint of the construction.
Augments the OtherConstruction with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1927
OuterCeilingSurface
Definition:
An OuterCeilingSurface is a surface that belongs to the outer building shell with the orientation pointing downwards. An example is the ceiling of a loggia.
Augments the OuterCeilingSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 1930
OuterFloorSurface
Definition:
An OuterFloorSurface is a surface that belongs to the outer construction shell with the orientation pointing upwards. An example is the floor of a loggia.
Augments the WindowSurface with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.15.2 Data Types
Table 1946
ADEOfAbstractConstruction
Definition:
ADEOfAbstractConstruction acts as a hook to define properties within an ADE that are to be added to AbstractConstruction.
Subclass of:
None
Stereotype:
«DataType»
Table 1948
ADEOfAbstractConstructionSurface
Definition:
ADEOfAbstractConstructionSurface acts as a hook to define properties within an ADE that are to be added to AbstractConstructionSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1950
ADEOfAbstractConstructiveElement
Definition:
ADEOfAbstractConstructiveElement acts as a hook to define properties within an ADE that are to be added to AbstractConstructiveElement.
Subclass of:
None
Stereotype:
«DataType»
Table 1952
ADEOfAbstractFillingElement
Definition:
ADEOfAbstractFillingElement acts as a hook to define properties within an ADE that are to be added to AbstractFillingElement.
Subclass of:
None
Stereotype:
«DataType»
Table 1954
ADEOfAbstractFillingSurface
Definition:
ADEOfAbstractFillingSurface acts as a hook to define properties within an ADE that are to be added to AbstractFillingSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1956
ADEOfAbstractFurniture
Definition:
ADEOfAbstractFurniture acts as a hook to define properties within an ADE that are to be added to AbstractFurniture.
Subclass of:
None
Stereotype:
«DataType»
Table 1958
ADEOfAbstractInstallation
Definition:
ADEOfAbstractInstallation acts as a hook to define properties within an ADE that are to be added to AbstractInstallation.
Subclass of:
None
Stereotype:
«DataType»
Table 1960
ADEOfCeilingSurface
Definition:
ADEOfCeilingSurface acts as a hook to define properties within an ADE that are to be added to a CeilingSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1962
ADEOfDoor
Definition:
ADEOfDoor acts as a hook to define properties within an ADE that are to be added to a Door.
Subclass of:
None
Stereotype:
«DataType»
Table 1964
ADEOfDoorSurface
Definition:
ADEOfDoorSurface acts as a hook to define properties within an ADE that are to be added to a DoorSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1966
ADEOfFloorSurface
Definition:
ADEOfFloorSurface acts as a hook to define properties within an ADE that are to be added to a FloorSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1968
ADEOfGroundSurface
Definition:
ADEOfGroundSurface acts as a hook to define properties within an ADE that are to be added to a GroundSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1970
ADEOfInteriorWallSurface
Definition:
ADEOfInteriorWallSurface acts as a hook to define properties within an ADE that are to be added to an InteriorWallSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1972
ADEOfOtherConstruction
Definition:
ADEOfOtherConstruction acts as a hook to define properties within an ADE that are to be added to an OtherConstruction.
Subclass of:
None
Stereotype:
«DataType»
Table 1974
ADEOfOuterCeilingSurface
Definition:
ADEOfOuterCeilingSurface acts as a hook to define properties within an ADE that are to be added to an OuterCeilingSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1976
ADEOfOuterFloorSurface
Definition:
ADEOfOuterFloorSurface acts as a hook to define properties within an ADE that are to be added to an OuterFloorSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1978
ADEOfRoofSurface
Definition:
ADEOfRoofSurface acts as a hook to define properties within an ADE that are to be added to a RoofSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1980
ADEOfWallSurface
Definition:
ADEOfWallSurface acts as a hook to define properties within an ADE that are to be added to a WallSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1982
ADEOfWindow
Definition:
ADEOfWindow acts as a hook to define properties within an ADE that are to be added to a Window.
Subclass of:
None
Stereotype:
«DataType»
Table 1984
ADEOfWindowSurface
Definition:
ADEOfWindowSurface acts as a hook to define properties within an ADE that are to be added to a WindowSurface.
Subclass of:
None
Stereotype:
«DataType»
Table 1986
ConstructionEvent
Definition:
A ConstructionEvent is a data type used to describe a specific event that is associated with a construction. Examples are the issuing of a building permit or the renovation of a building.
Specifies the value of the height above or below ground. [cf. INSPIRE]
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.15.3 Basic Types
none
11.15.4 Unions
none
11.15.5 Code Lists
Table 1995
DoorClassValue
Definition:
DoorClassValue is a code list used to further classify a Door.
Stereotype:
«CodeList»
Table 1997
DoorFunctionValue
Definition:
DoorFunctionValue is a code list that enumerates the different purposes of a Door.
Stereotype:
«CodeList»
Table 1999
DoorUsageValue
Definition:
DoorUsageValue is a code list that enumerates the different uses of a Door.
Stereotype:
«CodeList»
Table 2001
ElevationReferenceValue
Definition:
ElevationReferenceValue is a code list that enumerates the different elevation reference levels used to measure construction heights.
Stereotype:
«CodeList»
Table 2003
EventValue
Definition:
EventValue is a code list that enumerates the different events of a construction.
Stereotype:
«CodeList»
Table 2005
OtherConstructionClassValue
Definition:
OtherConstructionClassValue is a code list used to further classify an OtherConstruction.
Stereotype:
«CodeList»
Table 2007
OtherConstructionFunctionValue
Definition:
OtherConstructionFunctionValue is a code list that enumerates the different purposes of an OtherConstruction.
Stereotype:
«CodeList»
Table 2009
OtherConstructionUsageValue
Definition:
OtherConstructionUsageValue is a code list that enumerates the different uses of an OtherConstruction.
Stereotype:
«CodeList»
Table 2011
WindowClassValue
Definition:
WindowClassValue is a code list used to further classify a Window.
Stereotype:
«CodeList»
Table 2013
WindowFunctionValue
Definition:
WindowFunctionValue is a code list that enumerates the different purposes of a Window.
Stereotype:
«CodeList»
Table 2015
WindowUsageValue
Definition:
WindowUsageValue is a code list that enumerates the different uses of a Window.
Stereotype:
«CodeList»
11.15.6 Enumerations
Table 2017
ConditionOfConstructionValue
Definition:
ConditionOfConstructionValue enumerates different conditions of a construction. [cf. INSPIRE]
StereoType:
<<Enumeration>>
Literal value
Definition
declined
Indicates that the construction cannot be used under normal conditions, though its main elements (walls, roof) are still present. [cf. INSPIRE]
demolished
Indicates that the construction has been demolished. There are no more visible remains. [cf. INSPIRE]
functional
Indicates that the construction is functional. [cf. INSPIRE]
projected
Indicates that the construction is being designed. Construction works have not yet started. [cf. INSPIRE]
ruin
Indicates that the construction has been partly demolished and some main elements (roof, walls) have been destroyed. There are some visible remains of the construction. [cf. INSPIRE]
underConstruction
Indicates that the construction is under construction and not yet functional. This applies only to the initial construction works of the construction and not to maintenance work. [cf. INSPIRE]
Table 2020
HeightStatusValue
Definition:
HeightStatusValue enumerates the different methods used to capture a height. [cf. INSPIRE]
StereoType:
<<Enumeration>>
Literal value
Definition
estimated
Indicates that the height has been estimated and not measured. [cf. INSPIRE]
measured
Indicates that the height has been (directly or indirectly) measured. [cf. INSPIRE]
Table 2023
RelationToConstruction
Definition:
RelationToConstruction is an enumeration used to describe whether an installation is positioned inside and/or outside of a construction.
StereoType:
<<Enumeration>>
Literal value
Definition
inside
Indicates that the installation is positioned inside of the construction.
outside
Indicates that the installation is positioned outside of the construction.
bothInsideAndOutside
Indicates that the installation is positioned inside as well as outside of the construction.
11.16 Bridge
Table 2026
Description:
The Bridge module supports representation of thematic and spatial aspects of bridges, bridge parts, bridge installations, and interior bridge structures.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.16.1 Classes
Table 2027
AbstractBridge
Definition:
AbstractBridge is an abstract superclass representing the common attributes and associations of the classes Bridge and BridgePart.
Augments AbstractBridge with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2031
Bridge
Definition:
A Bridge represents a structure that affords the passage of pedestrians, animals, vehicles, and service(s) above obstacles or between two points at a height above ground. [cf. ISO 6707-1]
Augments the Bridge with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2035
BridgeConstructiveElement
Definition:
A BridgeConstructiveElement is an element of a bridge which is essential from a structural point of view. Examples are pylons, anchorages, slabs, beams.
Augments the BridgeFurniture with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2041
BridgeInstallation
Definition:
A BridgeInstallation is a permanent part of a Bridge (inside and/or outside) which does not have the significance of a BridgePart. In contrast to BridgeConstructiveElements, a BridgeInstallation is not essential from a structural point of view. Examples are stairs, antennas or railways.
Augments the BridgeInstallation with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2044
BridgePart
Definition:
A BridgePart is a physical or functional subdivision of a Bridge. It would be considered a Bridge, if it were not part of a collection of other BridgeParts.
Augments the BridgePart with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2047
BridgeRoom
Definition:
A BridgeRoom is a space within a Bridge or BridgePart intended for human occupancy (e.g. a place of work or recreation) and/or containment (storage) of animals or things. A BridgeRoom is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
Augments the BridgeRoom with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.16.2 Data Types
Table 2051
ADEOfAbstractBridge
Definition:
ADEOfAbstractBridge acts as a hook to define properties within an ADE that are to be added to AbstractBridge.
Subclass of:
None
Stereotype:
«DataType»
Table 2053
ADEOfBridge
Definition:
ADEOfBridge acts as a hook to define properties within an ADE that are to be added to a Bridge.
Subclass of:
None
Stereotype:
«DataType»
Table 2055
ADEOfBridgeConstructiveElement
Definition:
ADEOfBridgeConstructiveElement acts as a hook to define properties within an ADE that are to be added to a BridgeConstructiveElement.
Subclass of:
None
Stereotype:
«DataType»
Table 2057
ADEOfBridgeFurniture
Definition:
ADEOfBridgeFurniture acts as a hook to define properties within an ADE that are to be added to a BridgeFurniture.
Subclass of:
None
Stereotype:
«DataType»
Table 2059
ADEOfBridgeInstallation
Definition:
ADEOfBridgeInstallation acts as a hook to define properties within an ADE that are to be added to a BridgeInstallation.
Subclass of:
None
Stereotype:
«DataType»
Table 2061
ADEOfBridgePart
Definition:
ADEOfBridgePart acts as a hook to define properties within an ADE that are to be added to a BridgePart.
Subclass of:
None
Stereotype:
«DataType»
Table 2063
ADEOfBridgeRoom
Definition:
ADEOfBridgeRoom acts as a hook to define properties within an ADE that are to be added to a BridgeRoom.
Subclass of:
None
Stereotype:
«DataType»
11.16.3 Basic Types
none
11.16.4 Unions
none
11.16.5 Code Lists
Table 2065
BridgeClassValue
Definition:
BridgeClassValue is a code list used to further classify a Bridge.
Stereotype:
«CodeList»
Table 2067
BridgeConstructiveElementClassValue
Definition:
BridgeConstructiveElementClassValue is a code list used to further classify a BridgeConstructiveElement.
Stereotype:
«CodeList»
Table 2069
BridgeConstructiveElementFunctionValue
Definition:
BridgeConstructiveElementFunctionValue is a code list that enumerates the different purposes of a BridgeConstructiveElement.
Stereotype:
«CodeList»
Table 2071
BridgeConstructiveElementUsageValue
Definition:
BridgeConstructiveElementUsageValue is a code list that enumerates the different uses of a BridgeConstructiveElement.
Stereotype:
«CodeList»
Table 2073
BridgeFunctionValue
Definition:
BridgeFunctionValue is a code list that enumerates the different purposes of a Bridge.
Stereotype:
«CodeList»
Table 2075
BridgeFurnitureClassValue
Definition:
BridgeFurnitureClassValue is a code list used to further classify a BridgeFurniture.
Stereotype:
«CodeList»
Table 2077
BridgeFurnitureFunctionValue
Definition:
BridgeFurnitureFunctionValue is a code list that enumerates the different purposes of a BridgeFurniture.
Stereotype:
«CodeList»
Table 2079
BridgeFurnitureUsageValue
Definition:
BridgeFurnitureUsageValue is a code list that enumerates the different uses of a BridgeFurniture.
Stereotype:
«CodeList»
Table 2081
BridgeInstallationClassValue
Definition:
BridgeInstallationClassValue is a code list used to further classify a BridgeInstallation.
Stereotype:
«CodeList»
Table 2083
BridgeInstallationFunctionValue
Definition:
BridgeInstallationFunctionValue is a code list that enumerates the different purposes of a BridgeInstallation.
Stereotype:
«CodeList»
Table 2085
BridgeInstallationUsageValue
Definition:
BridgeInstallationUsageValue is a code list that enumerates the different uses of a BridgeInstallation.
Stereotype:
«CodeList»
Table 2087
BridgeRoomClassValue
Definition:
BridgeRoomClassValue is a code list used to further classify a BridgeRoom.
Stereotype:
«CodeList»
Table 2089
BridgeRoomFunctionValue
Definition:
BridgeRoomFunctionValue is a code list that enumerates the different purposes of a BridgeRoom.
Stereotype:
«CodeList»
Table 2091
BridgeRoomUsageValue
Definition:
BridgeRoomUsageValue is a code list that enumerates the different uses of a BridgeRoom.
Stereotype:
«CodeList»
Table 2093
BridgeUsageValue
Definition:
BridgeUsageValue is a code list that enumerates the different uses of a Bridge.
Stereotype:
«CodeList»
11.16.6 Enumerations
none
11.17 Building
Table 2095
Description:
The Building module supports representation of thematic and spatial aspects of buildings, building parts, building installations, building subdivisions, and interior building structures.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.17.1 Classes
Table 2096
AbstractBuilding
Definition:
AbstractBuilding is an abstract superclass representing the common attributes and associations of the classes Building and BuildingPart.
Lists the heights of each storey above ground. The first value in the list denotes the height of the storey closest to the ground level, the last value denotes the height furthest away.
Lists the height of each storey below ground. The first value in the list denotes the height of the storey closest to the ground level, the last value denotes the height furthest away.
Specifies qualified elevations of the building subdivision in relation to a well-defined surface which is commonly taken as origin (e.g. geoid or water level). [cf. INSPIRE]
Augments AbstractBuildingSubdivision with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2104
Building
Definition:
A Building is a free-standing, self-supporting construction that is roofed, usually walled, and can be entered by humans and is normally designed to stand permanently in one place. It is intended for human occupancy (e.g. a place of work or recreation), habitation and/or shelter of humans, animals or things.
Augments the Building with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2108
BuildingConstructiveElement
Definition:
A BuildingConstructiveElement is an element of a Building which is essential from a structural point of view. Examples are walls, slabs, staircases, beams.
Augments the BuildingFurniture with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2114
BuildingInstallation
Definition:
A BuildingInstallation is a permanent part of a Building (inside and/or outside) which has not the significance of a BuildingPart. Examples are stairs, antennas, balconies or small roofs.
Augments the BuildingInstallation with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2117
BuildingPart
Definition:
A BuildingPart is a physical or functional subdivision of a Building. It would be considered a Building, if it were not part of a collection of other BuildingParts.
Augments the BuildingPart with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2120
BuildingRoom
Definition:
A BuildingRoom is a space within a Building or BuildingPart intended for human occupancy (e.g. a place of work or recreation) and/or containment of animals or things. A BuildingRoom is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
Augments the BuildingRoom with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2124
BuildingUnit
Definition:
A BuildingUnit is a logical subdivision of a Building. BuildingUnits are formed according to some homogeneous property like function, ownership, management, or accessibility. They may be separately sold, rented out, inherited, managed, etc.
Augments the BuildingUnit with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2128
Storey
Definition:
A Storey is typically a horizontal section of a Building. Storeys are not always defined according to the building structure, but can also be defined according to logical considerations.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.17.3 Basic Types
none
11.17.4 Unions
none
11.17.5 Code Lists
Table 2155
BuildingClassValue
Definition:
BuildingClassValue is a code list used to further classify a Building.
Stereotype:
«CodeList»
Table 2157
BuildingConstructiveElementClassValue
Definition:
BuildingConstructiveElementClassValue is a code list used to further classify a BuildingConstructiveElement.
Stereotype:
«CodeList»
Table 2159
BuildingConstructiveElementFunctionValue
Definition:
BuildingConstructiveElementFunctionValue is a code list that enumerates the different purposes of a BuildingConstructiveElement.
Stereotype:
«CodeList»
Table 2161
BuildingConstructiveElementUsageValue
Definition:
BuildingConstructiveElementUsageValue is a code list that enumerates the different uses of a BuildingConstructiveElement.
Stereotype:
«CodeList»
Table 2163
BuildingFunctionValue
Definition:
BuildingFunctionValue is a code list that enumerates the different purposes of a Building.
Stereotype:
«CodeList»
Table 2165
BuildingFurnitureClassValue
Definition:
BuildingFurnitureClassValue is a code list used to further classify a BuildingFurniture.
Stereotype:
«CodeList»
Table 2167
BuildingFurnitureFunctionValue
Definition:
BuildingFurnitureFunctionValue is a code list that enumerates the different purposes of a BuildingFurniture.
Stereotype:
«CodeList»
Table 2169
BuildingFurnitureUsageValue
Definition:
BuildingFurnitureUsageValue is a code list that enumerates the different uses of a BuildingFurniture.
Stereotype:
«CodeList»
Table 2171
BuildingInstallationClassValue
Definition:
BuildingInstallationClassValue is a code list used to further classify a BuildingInstallation.
Stereotype:
«CodeList»
Table 2173
BuildingInstallationFunctionValue
Definition:
BuildingInstallationFunctionValue is a code list that enumerates the different purposes of a BuildingInstallation.
Stereotype:
«CodeList»
Table 2175
BuildingInstallationUsageValue
Definition:
BuildingInstallationUsageValue is a code list that enumerates the different uses of a BuildingInstallation.
Stereotype:
«CodeList»
Table 2177
BuildingRoomClassValue
Definition:
BuildingRoomClassValue is a code list used to further classify a BuildingRoom.
Stereotype:
«CodeList»
Table 2179
BuildingRoomFunctionValue
Definition:
BuildingRoomFunctionValue is a code list that enumerates the different purposes of a BuildingRoom.
Stereotype:
«CodeList»
Table 2181
BuildingRoomUsageValue
Definition:
BuildingRoomUsageValue is a code list that enumerates the different uses of a BuildingRoom.
Stereotype:
«CodeList»
Table 2183
BuildingSubdivisionClassValue
Definition:
BuildingSubdivisionClassValue is a code list used to further classify a BuildingSubdivision.
Stereotype:
«CodeList»
Table 2185
BuildingSubdivisionFunctionValue
Definition:
BuildingSubdivisionFunctionValue is a code list that enumerates the different purposes of a BuildingSubdivision.
Stereotype:
«CodeList»
Table 2187
BuildingSubdivisionUsageValue
Definition:
BuildingSubdivisionUsageValue is a code list that enumerates the different uses of a BuildingSubdivision.
Stereotype:
«CodeList»
Table 2189
BuildingUsageValue
Definition:
BuildingUsageValue is a code list that enumerates the different uses of a Building.
Stereotype:
«CodeList»
Table 2191
RoofTypeValue
Definition:
RoofTypeValue is a code list that enumerates different roof types.
Stereotype:
«CodeList»
Table 2193
RoomElevationReferenceValue
Definition:
RoomElevationReferenceValue is a code list that enumerates the different elevation reference levels used to measure room heights.
Stereotype:
«CodeList»
11.17.6 Enumerations
none
11.18 Tunnel
Table 2195
Description:
The Tunnel module supports representation of thematic and spatial aspects of tunnels, tunnel parts, tunnel installations, and interior tunnel structures.
Parent Package:
CityGML
Stereotype:
«ApplicationSchema»
11.18.1 Classes
Table 2196
AbstractTunnel
Definition:
AbstractTunnel is an abstract superclass representing the common attributes and associations of the classes Tunnel and TunnelPart.
Augments AbstractTunnel with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2200
HollowSpace
Definition:
A HollowSpace is a space within a Tunnel or TunnelPart intended for certain functions (e.g. transport or passage ways, service rooms, emergency shelters). A HollowSpace is bounded physically and/or virtually (e.g. by ClosureSurfaces or GenericSurfaces).
Augments the TunnelFurniture with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2214
TunnelInstallation
Definition:
A TunnelInstallation is a permanent part of a Tunnel (inside and/or outside) which does not have the significance of a TunnelPart. In contrast to TunnelConstructiveElement, a TunnelInstallation is not essential from a structural point of view. Examples are stairs, antennas or railings.
Augments the TunnelInstallation with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
Table 2217
TunnelPart
Definition:
A TunnelPart is a physical or functional subdivision of a Tunnel. It would be considered a Tunnel, if it were not part of a collection of other TunnelParts.
Augments the TunnelPart with properties defined in an ADE.
Note: Unless otherwise specified, all attributes and role names have the stereotype «Property».
11.18.2 Data Types
Table 2220
ADEOfAbstractTunnel
Definition:
ADEOfAbstractTunnel acts as a hook to define properties within an ADE that are to be added to AbstractTunnel.
Subclass of:
None
Stereotype:
«DataType»
Table 2222
ADEOfHollowSpace
Definition:
ADEOfHollowSpace acts as a hook to define properties within an ADE that are to be added to a HollowSpace.
Subclass of:
None
Stereotype:
«DataType»
Table 2224
ADEOfTunnel
Definition:
ADEOfTunnel acts as a hook to define properties within an ADE that are to be added to a Tunnel.
Subclass of:
None
Stereotype:
«DataType»
Table 2226
ADEOfTunnelConstructiveElement
Definition:
ADEOfTunnelConstructiveElement acts as a hook to define properties within an ADE that are to be added to a TunnelConstructiveElement.
Subclass of:
None
Stereotype:
«DataType»
Table 2228
ADEOfTunnelFurniture
Definition:
ADEOfTunnelFurniture acts as a hook to define properties within an ADE that are to be added to a TunnelFurniture.
Subclass of:
None
Stereotype:
«DataType»
Table 2230
ADEOfTunnelInstallation
Definition:
ADEOfTunnelInstallation acts as a hook to define properties within an ADE that are to be added to a TunnelInstallation.
Subclass of:
None
Stereotype:
«DataType»
Table 2232
ADEOfTunnelPart
Definition:
ADEOfTunnelPart acts as a hook to define properties within an ADE that are to be added to a TunnelPart.
Subclass of:
None
Stereotype:
«DataType»
11.18.3 Basic Types
none
11.18.4 Unions
none
11.18.5 Code Lists
Table 2234
HollowSpaceClassValue
Definition:
HollowSpaceClassValue is a code list used to further classify a HollowSpace.
Stereotype:
«CodeList»
Table 2236
HollowSpaceFunctionValue
Definition:
HollowSpaceFunctionValue is a code list that enumerates the different purposes of a HollowSpace.
Stereotype:
«CodeList»
Table 2238
HollowSpaceUsageValue
Definition:
HollowSpaceUsageValue is a code list that enumerates the different uses of a HollowSpace.
Stereotype:
«CodeList»
Table 2240
TunnelClassValue
Definition:
TunnelClassValue is a code list used to further classify a Tunnel.
Stereotype:
«CodeList»
Table 2242
TunnelConstructiveElementClassValue
Definition:
TunnelConstructiveElementClassValue is a code list used to further classify a TunnelConstructiveElement.
Stereotype:
«CodeList»
Table 2244
TunnelConstructiveElementFunctionValue
Definition:
TunnelConstructiveElementFunctionValue is a code list that enumerates the different purposes of a TunnelConstructiveElement.
Stereotype:
«CodeList»
Table 2246
TunnelConstructiveElementUsageValue
Definition:
TunnelConstructiveElementUsageValue is a code list that enumerates the different uses of a TunnelConstructiveElement.
Stereotype:
«CodeList»
Table 2248
TunnelFunctionValue
Definition:
TunnelFunctionValue is a code list that enumerates the different purposes of a Tunnel.
Stereotype:
«CodeList»
Table 2250
TunnelFurnitureClassValue
Definition:
TunnelFurnitureClassValue is a code list used to further classify a TunnelFurniture.
Stereotype:
«CodeList»
Table 2252
TunnelFurnitureFunctionValue
Definition:
TunnelFurnitureFunctionValue is a code list that enumerates the different purposes of a TunnelFurniture.
Stereotype:
«CodeList»
Table 2254
TunnelFurnitureUsageValue
Definition:
TunnelFurnitureUsageValue is a code list that enumerates the different uses of a TunnelFurniture.
Stereotype:
«CodeList»
Table 2256
TunnelInstallationClassValue
Definition:
TunnelInstallationClassValue is a code list used to further classify a TunnelInstallation.
Stereotype:
«CodeList»
Table 2258
TunnelInstallationFunctionValue
Definition:
TunnelInstallationFunctionValue is a code list that enumerates the different purposes of a TunnelInstallation.
Stereotype:
«CodeList»
Table 2260
TunnelInstallationUsageValue
Definition:
TunnelInstallationUsageValue is a code list that enumerates the different uses of a TunnelInstallation.
Stereotype:
«CodeList»
Table 2262
TunnelUsageValue
Definition:
TunnelUsageValue is a code list that enumerates the different uses of a Tunnel.
Stereotype:
«CodeList»
11.18.6 Enumerations
none
12 Application Domain Extension (ADE)
An Application Domain Extension (ADE) is a formal and systematic extension of the CityGML Conceptual Model (CM) for a specific application or domain. The ADE is expressed in the form of a UML conceptual model. The domain data is mapped to a set of additional classes, attributes, and relations. ADEs may use elements from the CityGML CM to derive application-specific subclasses, to inject additional properties, to associate application data with predefined CityGML content, or to define value domains for attributes.
The ADE mechanism allows application-specific information to be aligned with the CityGML CM in a well-structured and systematic way. By this means, CityGML can be extended to meet the information needs of an application while at the same time preserving its concepts and semantic structures. Moreover, and in contrast to generic city objects and attributes, application data can be validated against the formal definition of an ADE to ensure semantic interoperability.
Previous versions of the CityGML Standard defined the ADE mechanism solely at the level of the XML Schema encoding. With CityGML 3.0, ADEs become platform-independent models at a conceptual level that can be mapped to multiple and different target encodings.
ADEs have successfully been implemented in practice and enable a wide range of applications and use cases based on the CityGML Standard. An overview and discussion of existing ADEs is provided in [[Biljecki2018]].
12.1 General Rules for ADEs
An ADE shall be defined as a UML conceptual model in accordance with the General Feature Model and the rules for creating application schemas in UML as specified in ISO 19109 and the rules and constraints for using UML to model geographic information as specified in ISO 19103. The UML notations and stereotypes used in the CityGML conceptual model should also be applied to corresponding model elements in an ADE.
Every ADE shall be organized into one or more UML packages having globally unique namespaces and containing all UML model elements defined by the ADE. An ADE may additionally import and use predefined classes from external conceptual UML models such as the CityGML modules or the standardized schemas of the ISO 19100 series of International Standards.
12.2 Defining New ADE Model Elements
Following ISO 19109, the primary view of geospatial information and the core element of application schemas is the feature. ADEs therefore typically extend CityGML by defining new feature types appropriate to the application area together with additional content such as object types, data types, code lists, and enumerations.
Every feature type in an ADE shall be derived either directly or indirectly from the CityGML root feature type Core::AbstractFeature or, depending on its type and characteristics, from a more appropriate subclass thereof. According to the general CityGML space concept, features representing spaces or space boundaries shall be derived either directly or indirectly from Core::AbstractSpace or Core::AbstractSpaceBoundary respectively. UML classes representing top-level feature types shall use the «TopLevelFeatureType» stereotype.
In contrast to feature types, object types and data types are not required to be derived from a predefined CityGML class unless explicitly stated otherwise.
ADE classes may have an unlimited number of attributes and associations in addition to those inherited from their parents. Attributes can be modelled with either simple or complex data types. To ensure semantic interoperability, the predefined types from CityGML or the standardized schemas of the ISO 19100 series of International Standards should be used wherever appropriate. This includes, amongst others, basic types from ISO/TS 19103, geometry and topology objects from ISO 10107, and temporal geometry and topology objects from ISO 19108.
If a predefined type is not available, ADEs can either define their own data types or import data types from external conceptual models. This explicitly includes the possibility of defining new geometry types not offered by ISO 19107. Designers of an ADE should however note that software might not be able to properly identify and consume such geometry types.
A feature type capturing a real-world feature with geometry should be derived either directly or indirectly from Core::AbstractSpace or Core::AbstractSpaceBoundary. By this means, the CityGML predefined spatial properties and the associated LOD concept are inherited and available for the feature type. If, however, these superclasses are either inappropriate or lack a spatial property required to represent the feature, an ADE may define new and additional spatial properties. If such a spatial property should belong to one of the predefined LODs, then the property name shall start with the prefix “lodX”, where X is to be replaced by an integer value between 0 and 3 indicating the target LOD. This enables software to derive the LOD of the geometry.
Constraints on model elements should be expressed using a formal language such as the Object Constraint Language (OCL). The ADE specifies the manner of application of constraints. However, following the CityGML conceptual model, constraints should at least be expressed on ADE subclasses of Core::AbstractSpace to limit the types of space boundaries (i.e., instances of Core::AbstractSpaceBoundary) that may be used to model the boundary of a space object.
12.3 Augmenting CityGML Feature Types with Additional ADE Properties
If a predefined CityGML feature type lacks one or more properties required for a specific application, a feasible solution in CityGML 2.0 was to derive a new ADE feature type as subclass of the CityGML class and to add the properties to this subclass. While conceptually clean, this approach also faces drawbacks. If multiple ADEs require additional properties for the same CityGML feature type, this will lead to many subclasses of this feature type in different ADE namespaces. Information about the same real-world feature might therefore be spread over various instances of the different feature classes in an encoding making it difficult for software to consume the feature data.
For this reason, CityGML 3.0 provides a way to augment the predefined CityGML feature types with additional properties from the ADE domain without the need for subclassing. Each CityGML feature type has an extension attribute of name “adeOfFeatureTypeName” and type “ADEOfFeatureTypeName”, where FeatureTypeName is replaced by the class name in which the attribute is defined. For example, the Building::Building class offers the attribute adeOfBuilding of type Building::ADEOfBuilding. Each of these extension attributes can occur zero to unlimited times, and the attribute types are defined as abstract and empty data types.
If an ADE augments a specific CityGML feature type with additional ADE properties, the ADE shall create a subclass of the corresponding abstract data type associated with the feature class. This subclass shall also be defined as data type using the stereotype «DataType». The additional application-specific attributes and associations are then modelled as properties of the ADE subclass. This may include, amongst others, attributes with simple or complex data type, spatial properties or associations to other object and feature types from the ADE or external models such as CityGML.
The predefined “ADEOfFeatureTypeName” data types are called “hooks” because they are used as the head of a hierarchy of ADE subclasses attaching application-specific properties. When subclassing the “hook” of a specific CityGML feature type in an ADE, the properties defined in the subclass can be used for that feature type as well as for all directly or indirectly derived feature types, including feature types defined in the same or another ADE.
Multiple distinct ADEs can use the “hook” mechanism to define additional ADE properties for the same CityGML feature type. Since the “adeOfFeatureTypeName” attribute may occur multiple times, the various ADE properties can be exchanged as part of the same CityGML feature instance in an encoding. Software can therefore easily consume the default CityGML feature data plus the additional properties from the different ADEs.
Content from unknown or unsupported ADEs may be ignored by an application or service consuming an encoded CityGML model.
Designers of an ADE should favor using this “hook” mechanism over subclassing a CityGML feature type when possible. If an ADE must enable other ADEs to augment its own feature types (so-called ADE of an ADE), then it shall implement “hooks” for its feature types following the same schema and naming concept as in the CityGML conceptual model.
The UML fragment in Figure 14 shows an example for using the “hook” mechanism. For more details on this and other example ADEs, please see the CityGML 3.0 User Guide for an example ADE.
Figure 14 — The CityGML feature type Building is augmented with additional ADE properties by defining the data type EnergyProperties as a subclass of the ADE data type ADEOfBuilding.
12.4 Encoding of ADEs
This document only addresses the conceptual modelling of ADEs. Rules and constraints for mapping a conceptual ADE model to a target encoding are expected to be defined in a corresponding CityGML Encoding Standard. If supported, an ADE may provide additional mapping rules and constraints in conformance with a corresponding CityGML Encoding Standard.
12.5 Requirements and Recommendations
The following requirements and recommendations specify how ADEs shall be used as an extension capability to the CityGML Conceptual Model.
Any extension to the CityGML Conceptual Model should be a faithful continuation of the styles and techniques used in that model. The following Requirements and Recommendations define a “faithful continuation”.
Table 2265
Requirement 18
/req/ade/uml
An ADE SHALL be defined as conceptual model in UML in accordance with the conceptual modelling framework of the ISO 19100 series of International Standards
A
The UML model SHALL adhere to the General Feature Model as specified in ISO 19109.
B
The UML model SHALL adhere to rules and constraints for application schemas as specified in ISO/TS 19103.
C
Every ADE SHALL be organized into one or more UML packages having globally unique namespaces and containing all UML model elements defined by the ADE.
Unresolved directive in sections/clause_10_application_domain_extension.adoc — include::recommendations/ADE/REC_ADE_UML.adoc[]
12.5.2 Classes
The following Requirements and Recommendations define how CityGML classes should be extended by an ADE.
Table 2266
Requirement 19
/req/ade/elements
ADEs typically extend CityGML by defining new Feature Types together with additional content such as Object Types, Data Types, Code Lists, and Enumerations.
A
Every Feature Type in an ADE SHALL be derived either directly or indirectly from the CityGML root Feature Type core:AbstractFeature or a subclass thereof.
B
UML classes representing Top-Level Feature Types SHALL use the «TopLevelFeatureType» stereotype.
C
Features representing spaces or space boundaries SHALL be derived either directly or indirectly from core:AbstractSpace or core:AbstractSpaceBoundary respectively.
D
An ADE may define new and additional spatial properties. If such a spatial property should belong to a predefined LOD, then the property name SHALL start with the prefix “lodX”, where X is an integer value indicating the target LOD.
Unresolved directive in sections/clause_10_application_domain_extension.adoc — include::recommendations/ADE/REC_ADE_Elements.adoc[]
12.5.3 Properties
The following Requirements define how to use the CityGML extension properties to add attributes to an existing CityGML Feature Type.
Table 2267
Requirement 20
/req/ade/properties
Every Feature Type includes an extension property (hook) of type “ADEOf<FeatureTypeName>” where <FeatureTypeName> is the name of that Feature Type. To add an extension property to a Feature Type:
A
The ADE SHALL create a subclass of the abstract data type associated with the hook.
B
This subclass SHALL be defined as a data type using the stereotype «DataType».
C
Application-specific attributes and associations SHALL be modeled as properties of the ADE subclass.
Annex A (normative)
Abstract Test Suite (Normative)
A.1 Introduction
CityGML 3.0 is a Conceptual Model. Since it is agnostic to implementing technologies, an Executable Test Script is not feasible. It becomes the responsibility of the Implementation Specifications to provide evidence of conformance. This evidence should be provided as an annex to the Implementation Specification document.
The test method specified in this ATS is manual inspection. Automated methods may be used where they exist.
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Core.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Appearance.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_CityFurniture.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_CityObjectGroup.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Dynamizer.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Generics.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_LandUse.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_PointCloud.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Relief.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Transportation.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Vegetation.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Versioning.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_WaterBody.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Construction.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Bridge.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Building.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_Tunnel.adoc[]
Unresolved directive in sections/annex-ats.adoc — include::abstract_tests/ATS_ADE.adoc[]
Annex B (normative)
Revision History
Table B.1
Date
Release
Editor
Primary clauses modified
Description
2020-06-04
0.9.0
C. Heazel
all
Draft for review
2020-06-07
0.9.1
T. H. Kolbe
Chapter 10
Bibliography was added
2020-06-08
0.9.2
C. Nagel
Chapter 10
Chapter on ADE mechanism was added
2020-06-11
0.9.3
T. H. Kolbe
Chapter 7
Overview chapter on CityGML was added
2020-06-11
0.9.4
T. Kutzner
Chapter 0
List of participants and submitters was added
2020-08-05
0.9.5
T. Kutzner
Chapter 8
Boundary constraints were added
2020-08-05
0.9.6
C. Heazel, T. Kutzner
Chapter 8
UML update
Annex C (normative)
Glossary
conformance test class
The set of conformance test modules that must be applied to receive a single certificate of
conformance
[OGC 08-131r3, definition 4.4]
feature
An abstraction of real world phenomena
[ISO 19101-1:2014, definition 4.1.11]
feature attribute
A characteristic of a feature
[ISO 19101-1:2014, definition 4.1.12]
feature type
A class of features having common characteristics
[ISO 19156:2011, definition 4.7]
measurement
A set of operations having the object of determining the value of a quantity
[ISO 19101-2:2018, definition 3.21] / [VIM:1993, 2.1]
model
An abstraction of some aspects of reality
[ISO 19109:2015, definition 4.15]
observation
The act of measuring or otherwise determining the value of a property
[ISO 19156:2011, definition 4.11]
observation procedure
A method, algorithm or instrument, or system of these, which may be used in making an
observation
[ISO 19156:2011, 4.12]
observation result
An estimate of the value of a property determined through a known observation procedure
[ISO 19156:2011, 4.14]
property
A facet or attribute of an object referenced by a name.
[ISO 19143:2010, definition 4.21]
requirements class
The aggregate of all requirement modules that must all be satisfied to satisfy a conformance
test class
[OGC 08-131r3, definition 4.19]
schema
The formal description of a model
[ISO 19101-1:2014, definition 4.1.34]
sensor
A type of observation procedure that provides the estimated value of an observed
property at its output
[OGC 08-094r1, definition 4.5]
Standardization Target
An entity to which some requirements of a standard apply
[OGC 08-131r3, definition 4.23]
timeseries
A sequence of data values which are ordered in time
[OGC 15-043r3]
universe of discourse
View of the real or hypothetical world that includes everything of interest
[ISO 19101-1:2014, definition 4.1.38]
version
Particular variation of a spatial object
[INSPIRE Glossary]
C.1 ISO Concepts
The following concepts from the ISO TC211 Harmonized UML model are referenced by the CityGML Conceptual UML model but do not play a major role in its’ definition. They are provided here to support a more complete understanding of the model.
Area
The measure of the physical extent of any topologically 2-D geometric object. Usually measured in “square” units of length.
[Clause 6]
Boolean
Boolean is the mathematical datatype associated with two-valued logic
[Clause 6]
CC_CoordinateOperation
A mathematical operation on coordinates that transforms or converts coordinates to another coordinate reference system.
[Clause 6]
Character
A symbol from a standard character-set.
[Clause 6]
CharacterString
Characterstring is a family of datatypes which represent strings of symbols from standard character-sets.
[Clause 6]
CRS
Coordinate reference system which is usually single but may be compound.
[Clause 6]
CV_DiscreteCoverage
A subclass of CV_Coverage that returns a single record of values for any direct position within a single geometric object in its spatiotemporal domain.
[Clause 6]
CV_DomainObject
An element of the domain of the CV_Coverage. It is an aggregation of objects that may include any combination of GM_Objects (ISO 19107:2003), TM_GeometricPrimitives (ISO 10108), or spatial or temporal objects defined in other standards, such as the CV_GridPoint defined in this International Standard.
[Clause 6]
CV_GridPointValuePair
A subtype of CV_GeometryValuePair that has a GM_GridPoint as the value of its geometry attribute.
[Clause 6]
CV_GridValuesMatrix
The geometry represented by the various offset vectors is in the image plane of the grid.
[Clause 6]
CV_ReferenceableGrid
A subclass of CV_Coverage that relates the grid coordinates to an external coordinate reference system.
[Clause 6]
Date
Date gives values for year, month and day. Representation of Date is specified in ISO 8601. Principles for date and time are further discussed in ISO 19108.
[Clause 6]
DateTime
A DateTime is a combination of a date and a time types. Representation of DateTime is specified in ISO 8601. Principles for date and time are further discussed in ISO 19108.
[Clause 6]
Distance
Used as a type for returning distances and possibly lengths.
[Clause 6]
Engineering CRS
A contextually local coordinate reference system which can be divided into two broad categories:
earth-fixed systems applied to engineering activities on or near the surface of the earth;
CRSs on moving platforms such as road vehicles, vessels, aircraft or spacecraft.
[Clause 6]
Generic Name
Generic Name is the abstract class for all names in a NameSpace. Each instance of a GenericName is either a LocalName or a ScopedName.
[Clause 6]
Geometry
Geometry is the root class of the geometric object taxonomy and supports interfaces common to all geographically referenced geometric objects.
[Clause 6]
GM_CompositePoint
A GM_Complex containing one and only one GM_Point.
[Clause 6]
GM_CompositeSolid
A set of geometric solids adjoining one another along common boundary geometric surfaces
[Clause 6]
GM_GenericSurface
GM_Surface and GM_SurfacePatch both represent sections of surface geometry, and therefore share a number of operation signatures. These are defined in the interface class GM_GenericSurface.
[Clause 6]
GM_LineString
Consists of sequence of line segments, each having a parameterization like the one for GM_LineSegment
[Clause 6]
GM_MultiPrimitive
The root class for all primitive aggregates. The association role “element” shall be the set of GM_Primitives contained in this GM_MultiPrimitive. The attribute declaration here specializes the one at GM_Aggregate to include only GM_Primitives in this type of aggregate.
[Clause 6]
GM_OrientableSurface
A surface and an orientation inherited from GM_OrientablePrimitive. If the orientation is “+”, then the GM_OrientableSurface is a GM_Surface. If the orientation is “-”, then the GM_OrientableSurface is a reference to a GM_Surface with an upNormal that reverses the direction for this GM_OrientableSurface, the sense of “the top of the surface”.
[Clause 6]
GM_PolyhedralSurface
A GM_Surface composed of polygon surfaces (GM_Polygon) connected along their common boundary curves.
[Clause 6]
GM_Position
A union type consisting of either a DirectPosition or of a reference to a GM_Point from which a DirectPosition shall be obtained.
[Clause 6]
GM_Primitive
The abstract root class of the geometric primitives. Its main purpose is to define the basic “boundary” operation that ties the primitives in each dimension together.
[Clause 6]
Integer
An exact integer value, with no fractional part.
[Clause 6]
Internet of Things
The network of physical objects—“things”—that are embedded with sensors, software, and other technologies for the purpose of connecting and exchanging data with other devices and systems over the Internet. Wikipedia
IO_IdentifiedObjectBase
Supplementary identification and remarks information for a CRS or CRS-related object.
[Clause 6]
Length
The measure of distance as an integral, i.e. the limit of an infinite sum of distances between points on a curve.
[Clause 6]
Measure
The result from performing the act or process of ascertaining the extent, dimensions, or quantity of some entity.
[Clause 6]
Number
The base type for all number data, giving the basic algebraic operations.
[Clause 6]
Point
GM_Point is the basic data type for a geometric object consisting of one and only one point.
[Clause 6]
Real
The common binary Real finite implementation using base 2.
[Clause 6]
RS_ReferenceSystem
Description of a spatial and temporal reference system used by a dataset.
[Clause 6]
Scoped Name
ScopedName is a composite of a LocalName for locating another NameSpace and a GenericName valid in that NameSpace. ScopedName contains a LocalName as head and a GenericName, which might be a LocalName or a ScopedName, as tail.
[Clause 6]
Solid
GM_Solid, a subclass of GM_Primitive, is the basis for 3-dimensional geometry. The extent of a solid is defined by the boundary surfaces.
[Clause 6]
Time
Time is the designation of an instant on a selected time scale, astronomical or atomic. It is used in the sense of time of day.
[Clause 6]
TM_Duration
A data type to be used for describing length or distance in the temporal dimension.
[Clause 6]
TM_TemporalPosition
The position of a TM_Instant relative to a TM_ReferenceSystem.
[Clause 6]
Unit of Measure
Any of the systems devised to measure some physical quantity such distance or area or a system devised to measure such things as the passage of time.
[Clause 6]
URI
Uniform Resource Identifier (URI), is a compact string of characters used to identify or name a resource
[Clause 6]
Volume
Volume is the measure of the physical space of any 3-D geometric object.
[Clause 6]
C.2 Abbreviated terms
2D Two Dimensional
3D Three Dimensional
AEC Architecture, Engineering, Construction
ALKIS German National Standard for Cadastral Information
ATKIS German National Standard for Topographic and Cartographic Information
BIM Building Information Modeling
B-Rep Boundary Representation
bSI buildingSMART International
CAD Computer Aided Design
COLLADA Collaborative Design Activity
CSG Constructive Solid Geometry
DTM Digital Terrain Model
DXF Drawing Exchange Format
EuroSDR European Spatial Data Research Organisation
ESRI Environmental Systems Research Institute
FM Facility Management
GDF Geographic Data Files
GDI-DE Spatial Data Infrastructure Germany (Geodateninfrastruktur Deutschland)